[ietf-privacy] PPM Review of RFC 1614
[A quick trial of the random RFC tool.] An interesting historical snapshot of the early days of hypertext systems before WWW/HTML/HTTP had come to dominate everything and how they might be relevant to academic users. It even predates Internet Explorer! Mainly interesting for its lack of interest in security (mentioned in passing 3 times in 70 pages: twice to say that client side scripting won't be done in two separate systems including WWW because of security issues - well, it was half right - we now have scripting *and* security issues - and one comment that security would be needed for publication of commercial information) and being totally oblivious of any privacy concerns. Significant for Internet archaeologists and evolutionary biologists but not something that needs to be updated. Just thank your lucky stars (or not) that WWW used SGML/HTML rather than ISO MHEG part 1 coded in ASN.1. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: IETF 87 Registration Suspended
On Fri, 2013-07-05 at 00:11 -0400, Noel Chiappa wrote: From: John Levine jo...@taugh.com what's different in Berlin from Paris and Prague and Maastricht. The Germans have more 'zealous' tax collectors? :-) Noel It appears that the goalposts have been moved - the basic change came in a couple of years ago: http://www.uktrainingworldwide.com/BB/vat-rules-for-events-and-seminars.html but the proximal cause may be to do with an update from last September (and this was instigated in Germany): See page 159 of http://ec.europa.eu/taxation_customs/resources/documents/taxation/vat/key_documents/vat_committee/2012_guidelines-vat-committee-meetings_en.pdf This is probably ultimately down to the tightening of the inter-country trading rules after the clampdown on so-called carousel trading. But with the arcana of VAT rules ... who knows (certainly not me although I have tangled with a few of them)? Doubtless clearing this up will require a confrontation of tax lawyer and VAT officer at dawn in some shady forest glade. /Elwyn
New form of remote attendance [was Re: The Nominating Committee Process: Eligibility]
On Thu, 2013-06-27 at 12:44 +0100, Arturo Servin (probably did not intend to) wrote: What is the rationale of the requirement to attend psychically to meetings? I attend all meetings psychically so spriritual! Sorry.. couldn't resist. E.
Re: IAOC Website Updated
Hi, Ray. I also think it's good. On the same theme as Brian, the page is linked to from the 'IASA' link on the main IETF page. To make it clear what is going on, it would be good to put the title: IETF Administrative Support Activity at the top of the page. A couple of other nits: It might also be useful to add 'IASA/IAOC' to the header of the Announcements page. The 'Legal' and 'Subpoenas' pages contain significant duplication: The text in the 'Subpoenas' section of the 'Legal' page is a large subset of the text on the 'Subpoenas' page. Conversely, the 'Appeals' page under operations misses the text on the appeals process in BCP101 that is hidden under the 'Legal' page. Regards, Elwyn On Mon, 2013-06-24 at 16:36 +1200, Brian E Carpenter wrote: Hi Ray, I think it's very good. One micro-comment: the menu at the left is headed up by the IETF logo (which is in fact a link to the main site). I did find that momentarily confusing - maybe the first two items could be labelled IASA Home and About IASA to make it clear which menu this is? Best wishes Brian On 21/06/2013 06:59, IETF Administrative Director wrote: One of the IAOC goals for 2013 was to update the IAOC website to improve consistency, organization, linkage, and ease of use. I am pleased to announce that the IAOC site has been updated and is available now for your use at http://iaoc.ietf.org/. On the home page see a video of an Overview of the IAOC given by Chair Bob Hinden in Orlando that includes a discussion of venue selection and IETF finances. Also on the home page are recent announcements, as well as reports from IANA, the RFC Editor, the IETF Chair, the NomCom Chair, and more. The navigation bar makes it easy to find financial statements, minutes, meeting sponsorship opportunities, and much more. We hope you find this helpful, the IAOC as more transparent, and of course we welcome your feedback. Ray IETF Administrative Director PS: Going to IETF 87 in Berlin? The IAOC will be doing another overview session there, Sunday July 28 at 3:00 PM. Hope to see you there!
Re: Content-free Last Call comments
On 10/06/13 21:37, Pete Resnick wrote: Russ, our IAB chair and former IETF chair, just sent a message to the IETF list regarding a Last Call on draft-ietf-pkix-est. Here is the entire contents of his message, save quoting the whole Last Call request: On 6/10/13 1:45 PM, Russ Housley wrote: I have read the document, I a support publication on the standards track. Russ Pete, I write gen-art reviews. A proportion of them at IETF Last Call, give or take a bunch of boilerplate, consist of the word 'Ready'*. How do you distinguish the usefulness (or otherwise) of such a review from Russ' one liner? /Elwyn * and some of the others say 'Not ready' followed by some or many lines of comments.
Re: [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
On Fri, 2013-06-07 at 11:35 +0200, Magnus Westerlund wrote: Hi Elwyn, Many thanks for the detailed review. We will address the nits you have raised, but I cut them out of this reply to focus on the more substantial issues you have brought up. .. and thanks for the quick response. See inline below. OK. I think the responses clear those issues. I have done a little bit more on the Appendices and liaised a bit with Robert Sparks. 'Highlights': Appendix F: I missed that the text/parameter format appeared in the examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the definitions of these methods what encodings are acceptable for the message bodies that may go with these methods and their responses. Clearly the new text/parameter MIME format is one. Is it the only one? I guess you could use a application/json or an XML format but I guess these would also either have to be called out explicitly in the method descriptions or put in as feature extensions. This needs to be clarified in the method descriptions (s13). The upshot of all this is that I think Appendix F needs to be pulled back into Section 20 as currently it is the only way to encode the message bodies. Appendix B: I appreciate that the state machine is illustrative and to an extent 'abstract'. However, the tables are really written to describe the state machine in the server: the action column mostly describes the events that come into the server (apart from the notify actions) - sending these 'events' are actions in the client. The 'real' state machine in the both the server and the client has a somewhat more complex form: I'd think that there was a STOPPED state in the server when the media has reached an end point and not been explictly paused and STARTING/PAUSING states in the client while the client waits for response to PLAY/PAUSE respectively. I think a little bit more explanation about the dual nature of the columns would solve the problem. Appendix C: Pending. Regards, Elwyn On 2013-06-06 02:11, Elwyn Davies wrote: I am an additional Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-rfc2326bis Reviewer: Elwyn Davies Review Date: 5 June 2013 IETF LC End Date: 5 JUne 2013 IESG Telechat date: (if known) - Summary: Almost ready. Generally this is an excellent and well written document, particularly given its size. There are a few minor issues to sort out mainly at the nit level and some consistency issues to fix up. The two issues that I have brought out below are really at what the IESG would call 'DISCUSS-DISCUSS' level. The issue of URI scheme redefinition may well have already been cleared by the URI expert - the draft does not do itself any favours here by failing to explain what the syntax changes are in s4.2; this raises immediate red flags that only start to fade a couple of hundred pages later. The rudimentary nature of the pipeline mechanism is carried over from RTSP 1.0. I'd like to be sure that this has been properly discussed in the WG as it looks pretty flaky to an outsider. There are several inconsistencies between various lists of headers that need sorting out and there is no definition of Proxy-Authorization in the ABNF. There are also a fairly large number of editorial nits but these are all localized and trivial to fix. Finally I have't had time to review the appendices (maybe there will be a follow up). Robert Sparks is the main gen-art reviewer for the document; he asked for additional eyes on the document given the size and his RAI background. Having (just) seen his review, I think we have both picked up on the URI scheme and pipeline issues. I am not sure that I concur with his view that there is significant normative material in the appendices - AFAICS the main protocol definition *is* in the main body of the document and the bits especiially in Appendices B and C are not the core of the protocol. However this is based on a very cursory glance through something like 75 pages of the document. However, I do concur with Robert's view that it needs a security expert to check the security stories. Major(ish) issues: s4.2: This section (re-)defines the URI schemes rtsp and rtsps. The last sentence of para 1 states that the 'details of the syntax' of the URIs 'have been changed'. Is this a reasonable thing to do? Has this been cleared with the URI expert reviewer? I am not entirely clear what the change involves and the draft doesn't explain exactly how the syntax has been altered and its consequences (if any) in s4.2. Some details are finally given in s22.14. These syntax changes where discussed in the reviews I got on the URI list. That resulted
Re: [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
On Fri, 2013-06-07 at 16:05 +0200, Magnus Westerlund wrote: Appendix F: I missed that the text/parameter format appeared in the examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the definitions of these methods what encodings are acceptable for the message bodies that may go with these methods and their responses. Exactly, that is intentional. These methods can use anything that has a MIME type. Also it has HTTP's mechanisms for determining what formats one supports. Clearly the new text/parameter MIME format is one. Is it the only one? It is the only one defined by IETF for this purpose. That is why it is in the appendix so that RTSP users shall have something to define the parameters they want in. However, they have to accept the limitations of a basic text format. I guess you could use a application/json or an XML format but I guess these would also either have to be called out explicitly in the method descriptions or put in as feature extensions. This needs to be clarified in the method descriptions (s13). The upshot of all this is that I think Appendix F needs to be pulled back into Section 20 as currently it is the only way to encode the message bodies. I can agree that the format negotiation for the bodies of GET/SET_PARAMETER is not clear. I will look at proposing some improvements of the text related to the handling of method bodies and their format negotiation. Good. I don't see where the server tells what formats it accepts for either GET_PARAMETER or SET_PARAMETER. Also the Accept spec doesn't say anything about SET_PARAMETER. AFAICS the client could tell the server what formats it accepts as a side-effect of DESCRIBE but that's a bit arcane - and it is not clear how you would separate the formats for DESCRIBE from those for GET_PARAM and SET_PARAM. However, I am not pulling in Appendix F. It is an optional to use format for parameter value pairs that can be used in these methods, it is not required. Nor, does the specification define any parameters that are transferred using this interface. The things that are in the appendix are not core protocol, they represent either informational things, like the examples and the state machine. The other appendices are normative definitions of particular choices for things that can be combined or used with RTSP, like RTP as media transport. OK, it is possible to use GET_PARAM for basic requirements without using message bodies, so you can get away without defining a lowest common denominator format. However, the use of message bodies for SET_PARAM is RECOMMENDED so it seems a little odd not to ensure that server and client will have at least one format in common. (And its not as if we are dealing with a hugely complicated bit of spec for text/parameters! :-) ). Then, given the example in GET_PARAMETER it seems sensible to advise implementing text/parameters as the default for GET_PARAM also. /Elwyn
Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
I am an additional Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-rfc2326bis Reviewer: Elwyn Davies Review Date: 5 June 2013 IETF LC End Date: 5 JUne 2013 IESG Telechat date: (if known) - Summary: Almost ready. Generally this is an excellent and well written document, particularly given its size. There are a few minor issues to sort out mainly at the nit level and some consistency issues to fix up. The two issues that I have brought out below are really at what the IESG would call 'DISCUSS-DISCUSS' level. The issue of URI scheme redefinition may well have already been cleared by the URI expert - the draft does not do itself any favours here by failing to explain what the syntax changes are in s4.2; this raises immediate red flags that only start to fade a couple of hundred pages later. The rudimentary nature of the pipeline mechanism is carried over from RTSP 1.0. I'd like to be sure that this has been properly discussed in the WG as it looks pretty flaky to an outsider. There are several inconsistencies between various lists of headers that need sorting out and there is no definition of Proxy-Authorization in the ABNF. There are also a fairly large number of editorial nits but these are all localized and trivial to fix. Finally I have't had time to review the appendices (maybe there will be a follow up). Robert Sparks is the main gen-art reviewer for the document; he asked for additional eyes on the document given the size and his RAI background. Having (just) seen his review, I think we have both picked up on the URI scheme and pipeline issues. I am not sure that I concur with his view that there is significant normative material in the appendices - AFAICS the main protocol definition *is* in the main body of the document and the bits especiially in Appendices B and C are not the core of the protocol. However this is based on a very cursory glance through something like 75 pages of the document. However, I do concur with Robert's view that it needs a security expert to check the security stories. Major(ish) issues: s4.2: This section (re-)defines the URI schemes rtsp and rtsps. The last sentence of para 1 states that the 'details of the syntax' of the URIs 'have been changed'. Is this a reasonable thing to do? Has this been cleared with the URI expert reviewer? I am not entirely clear what the change involves and the draft doesn't explain exactly how the syntax has been altered and its consequences (if any) in s4.2. Some details are finally given in s22.14. Minor issues: s11, para 3: I guess that the WG decided that sticking with the RTSP 1.0 model of sending requests and worrying about success of prior prior pipelined requests was the right answer. I would have thought that it might have been helpful to provide qualifiers on the Pipelined-Requests header that allowed subsequent requests to be suppressed unless the previous command resulted in one of a given set of status codes with a 'reset' option to 'restart' the pipeline. It strikes me that this would avoid some irritating need to work out how to recover from arbitrary failures in a command chain in a client. Nits/editorial comments: General: s/i.e./i.e.,/; s/e.g./e.g.,/ General: Consistent usage of octet vs. byte (octet preferred). General: Consistent use of '(session) keep alive' vs. '(session) keep-alive' General: Consistent use of Base64 vs BASE64. s1, para 2, last sentence: s/delivered as a time-synchronized streams/delivered as time-synchronized streams/ s1. last para: s/used terms/terms used/ s1, last para: Need to expand SDP acronym. s2, para 1: s/considered use cases/use cases considered/ s2.1, para 1: s/completely out of bands/completely out of band/ s2.1, next to last para: It would be useful to provide a pointer to where the two URI schemes are defined (s4.2?) so it is clear these are internally defined and one needn't go looking for another doc. s2.2, para 5: s/uses client-selected identifier/uses a client-selected identifier/ s2.2, para 5: For consistency there should be a reference for s18.32 with Pipelined-Requests. s2.2, last para: For consistency there should be a reference for s18.29 with Media-Range. s2.3, para 1: Expand SMPTE acronym. s2.3, para 3: Reference s13.5 for PLAY_NOTIFY s2.3, para 5: The server should also regularly send every 5 minutes the current media range in a PLAY_NOTIFY request. Shouldn't this be configurable? s2.3, last para: If the client waits too long before resuming the pause point, the content may no longer be available. In this case the pause point will be adjusted to the end of the available media. I know this is a subjective choice, but I would have thought adjusting to the beginning of the available media would
Re: Time in the Air
On 31/05/13 20:18, Scott Brim wrote: On Friday, May 31, 2013, Dave Crocker wrote: On 5/31/2013 8:12 PM, Scott Brim wrote: We'll have multiple airships, one for each set of related meeting rooms. is dirigible a new term of endearment for an AD? Obviously the ADs have a small helicopter so they can get between dirigibles. Don't they use the ADs (Area Drones) controlled from the IESG bunker?
Re: call for ideas: tail-heavy IETF process
Similarly, AFAICS the 'IESG time' includes IETF last call and the inevitable delay caused by the quantized nature of IESG teleconferenes. On the average, this will be somewhere around 28-30 days (2 or 4 weeks in Last call according to document type plus an average of 1 week until the earliest possible teleconference and a fudge factor for weekends) which is an irreducible minimum imposed by our processes. There is not much the IESG can do to help on that. /Elwyn On Fri, 2013-05-10 at 08:09 +1200, Brian E Carpenter wrote: On 10/05/2013 01:13, John C Klensin wrote: --On Thursday, May 09, 2013 03:32 -0500 Spencer Dawkins spen...@wonderhamster.org wrote: So in this case, we're looking at RFC Editor state = Heather, please do something + some working group, please do something + author(s), please do something, and we can't tell how much time to attribute to each of these ... You could further add to that list RFC Production Center, please do something (different from an RSE wait, which is, or at least ought to be, more significant) and IESG or appropriate AD, please do something, which does happen. But the RFC Editor's numbers try (almost always successfully) to separate the two waiting on the RFC Editor Function to do something (Heather plus Production Center plus, in principle, Publisher) from the other states. Those other states could, from their point of view, be aggregated into stuck, someone else's problem. If we are looking for issues with IETF end-game process, we need to parse those, but that is a different sort of question in terms of data-gathering and reporting. All of which suggests that, ideally, the tracker would include a variable onTheHook for each draft, containing at all times the person or role responsible for the next step. That isn't necessarily implied by the state machine. For example, AUTH48 doesn't always imply that the author is on the hook - it may be that the author has asked the WG Chair to ask the WG for a quick review of a proposed last-minute change. At that point, the WG as a whole is on the hook. Brian
Re: Accessing tools from IETF pages
Both links work just fine from a selection of browsers/os/machines other than Msoft. (Firefox, Evolution, Chrome) It also works on an old version of IE8 but reports errors. Presumably turning off some strict error checking in IE allows it to display. Running the page through the W3C HTML validator reports 14 Errors and 3 Warnings: http://validator.w3.org/check?uri=http%3A%2F%2Ftools.ietf.org% 2Fcharset=%28detect+automatically% 29doctype=Inlinegroup=0user-agent=W3C_Validator%2F1.3+http%3A%2F% 2Fvalidator.w3.org%2Fservices /Elwyn On Wed, 2013-05-08 at 15:05 +0100, t.p. wrote: I wanted to submit an I-D so I wanted to access the tools, as I have done before, so I clicked on 'IETF Tools' from http://datatracker.ietf.org/wg/ and when that failed tried again with 'Tools Team Pages' from http://www.ietf.org/iesg/ with the same result. Can anyone else get to tools from that link? It resolves to http://tools.ietf.org/ which Internet Explorer (what else?) assures me cannot be displayed, either from the link or from typing it into the Open drop down. The trouble ticket drew a response of It sounds like the tools pages were experiencing some issues that have now been resolved. Well, for a few milliseconds, perhaps, but I get the same response 24x7x365x... Not that easily put off, I found a way around it (thank you, Google), but in the spirit of wanting others to be able to do what I can (with some difficulty) do, I would like those links to work (or to disappear). Tom Petch
Re: call for ideas: tail-heavy IETF process
On Fri, 2013-05-03 at 14:27 +0100, Stephen Farrell wrote: On 05/03/2013 01:59 PM, Thomas Narten wrote: If you look at the delays documents encounter (both in WG and in IESG review), the killer is long times between document revisions. Focus on understanding the *why* behind that and what steps could be taken to make improvements. Good point. I guess the obvious answers are not enough cycles and not enough concentrated cycles - designing and documenting a protocol in my experience requires a longish period of undisturbed concentration by the person with the editing crayon, and responsive, deep and immediate review by co-authors to generate fast turn round reviews of versions. Its hard enough keeping the in-brain implementation of the protocol running accurately day-by-day. If there are gaps of weeks rebooting the implementation wastes precious concentrated time. Probably putting a few people with no other commitments in a isolated space generates fastest results. Maybe we could get ISOC to provide a retreat space (or one per continent) for protocol designers? and, for newer authors, uncertainty about how to get stuff done, but are there other less obvious answers? (Input here might really help the IESG discussion btw since in the nature of things, we're less likely to realise what newer or less frequent participants find problematic.) One thing that might help: We have directorates and review panels. Can we distil any/more of their wisdom into checklists/guidance for protocol writers? Some is already there (not a complete list): BCP 72 for security considerations BCP 41 on congestion control BCP 61 on Strong Security Requirements Some stuff in RFC 6385 for gen-art [Some of this is getting a bit long in the tooth.] So what do you ... - think about when designing the security aspects/transport congestion aspects/... of a new protocol? - what triggers alarm bells/gold stars when you are reviewing the general principles/security aspects/congestion/ABNF/state machines/mib/xml/extensibility/ of a draft? Regards, Elwyn S.
Re: call for ideas: tail-heavy IETF process
On 01/05/13 21:05, Brian E Carpenter wrote: On 02/05/2013 05:59, Dave Crocker wrote: The blog nicely classes the problem as being too heavy-weight during final stages. The quick discussion thread seems focused on adding a moment at which the draft specification is considered 'baked'. I think that's still too late. What, you agree with your younger self? http://tools.ietf.org/html/draft-carpenter-icar-sirs-01 Apart from the non-diverse acronym, I still think that proposal was a good one. Brian Rereading the background document that lead to the SIRS proposal is also worthwhile: http://tools.ietf.org/html/draft-ietf-problem-issue-statement-00 I think the views in sections A.2.6. to A.2.9 are still pretty much applicable; judging from recent comments some people still think the situation with the IESG is a 'battle of wills'. I guess one way of summarising this whole problem might be: We set on a group of people (a WG) who by definition are supposed to work in 'common mode' on a particular problem in what is mostly a closed bubble. It's perhaps not entirely surprising that what comes out at IETF Last Call time has more than its fair share of 'common mode failures', symptoms of groupthink and blinkered views of the overall requirements for effective operation in the wider Internet. The comments in the 'problem' draft and the SIRS proposal reflect an attempt to suggest how the closed bubble can be kept in contact with the wider world. However, getting the relationship between outside reviewers and the WG teams right would be non-trivial - not to mention a significant organisational effort and a load on the reviewers. To be honest, AFAIK we have never attempted to quantify how much extra effort (if any) a SIRS-like exercise would require as compared with the existing directorate reviews. Personally, I don't believe that we should attempt to categorise some I-Ds as more significant than others. This requires 20-20 hindsight with which we are certainly not equipped. /Elwyn BTW Re the diversity discussion: take a look at the editorial panel on the problem draft - ok, its only along one of the dimensions. Jari might also remember a contribution he made to 'problem': o WG process is too slow, because of feeping creaturism, deadlocked conflicts or lack of worker bandwidth (Jari Arkko) I can certainly agree on the feeping creaturism! /E
Re: call for ideas: tail-heavy IETF process
On 01/05/13 21:05, Brian E Carpenter wrote: On 02/05/2013 05:59, Dave Crocker wrote: The blog nicely classes the problem as being too heavy-weight during final stages. The quick discussion thread seems focused on adding a moment at which the draft specification is considered 'baked'. I think that's still too late. What, you agree with your younger self? http://tools.ietf.org/html/draft-carpenter-icar-sirs-01 Apart from the non-diverse acronym, I still think that proposal was a good one. Brian Rereading the background document that lead to the SIRS proposal is also worthwhile: http://tools.ietf.org/html/draft-ietf-problem-issue-statement-00 I think the views in sections A.2.6. to A.2.9 are still pretty much applicable; judging from recent comments some people still think the situation with the IESG is a 'battle of wills'. I guess one way of summarising this whole problem might be: We set on a group of people (a WG) who by definition are supposed to work in 'common mode' on a particular problem in what is mostly a closed bubble. It's perhaps not entirely surprising that what comes out at IETF Last Call time has more than its fair share of 'common mode failures', symptoms of groupthink and blinkered views of the overall requirements for effective operation in the wider Internet. The comments in the 'problem' draft and the SIRS proposal reflect an attempt to suggest how the closed bubble can be kept in contact with the wider world. However, getting the relationship between outside reviewers and the WG teams right would be non-trivial - not to mention a significant organisational effort and a load on the reviewers. To be honest, AFAIK we have never attempted to quantify how much extra effort (if any) a SIRS-like exercise would require as compared with the existing directorate reviews. Personally, I don't believe that we should attempt to categorise some I-Ds as more significant than others. This requires 20-20 hindsight with which we are certainly not equipped. /Elwyn BTW Re the diversity discussion: take a look at the editorial panel on the problem draft - ok, its only along one of the dimensions. Jari might also remember a contribution he made to 'problem': o WG process is too slow, because of feeping creaturism, deadlocked conflicts or lack of worker bandwidth (Jari Arkko) I can certainly agree on the feeping creaturism! /E
Re: Purpose of IESG Review
On 15/04/13 15:45, Brian E Carpenter wrote: On 15/04/2013 15:23, Ted Lemon wrote: ... So in practice, although I feel great sympathy for this position, I think it's mistaken. I want the other ADs to comment on anything that they notice that looks like a problem. There's an important class of problem that can only be found by someone who is *not* a specialist - that is to say wording that's perfectly clear and unambiguous to someone very familiar with the topic, but is quite unclear to someone who isn't. This matters because we (presumably) want our specifications to be useful to people who are implementing or deploying them without already being members of the inner circle. Just to be specific, here is a piece of text that came out of a WG not so long ago. I have bowdlerised it: The Foobar standards [RFCxxx], [RFCyyy] provide useful generic functionality like blah, blah and blah for reducing the overhead in Boofar networks. This functionality can be partly applied to Bleep. That was it - a third party implementing Bleep was apparently supposed to guess which bits of those RFCs applied where. This led to a DISCUSS and seven months of delay before that partly was disambiguated. Was that inappropriate out-of-area review? Brian On 15/04/13 14:09, Jari Arkko wrote: [Responding to Dave Crocker] But what is tiring about this line of justification is its continuing failure to balance the analysis by looking at the costs and problems that come with it. Does it provide regular and sufficient benefit to justify its considerable costs? Agreed. I would say it usually does justify its costs - skimping on the QA is almost always a bad idea. Speaking also from a gen-art perspective, getting a level of clarity and ease of use into a document may take a little while for a number of reviewers and authors, but the costs and benefits need to include the effort of implementers, testers and future users who will not appreciate getting a product that doesn't interoperate because the spec was unclear or they missed a point that might have been 'obvious' to the original authors. The size of the affected population is much bigger after publication (at least if anybody actually cares about the RFC). I have to say that in my experience the seven months of delay that Brian cites is rather unusual. For the vast majority of documents, the sorts of clarification needed can be sorted out in a couple of rounds of email, and the results are unlikely to require recycling back to the WG. That being said, there certainly are documents where I wonder why anybody seriously thought the document was ready for publication; trying to fix the process 'tail heaviness' (as Jari describes it) would help if we could find a way. It could be argued that the tail process is just too polite. Once a document embarks on the publication process we seemingly inevitably send it through all those reviews resulting in multitudinous politely phrased DISCUSSes and comments when what it really needs is a blunt refusal followed by some competent editing. /Elwyn
Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first
Right.. they are mind expanding drugs. Essential for keeping us sane. /Elwyn Sent from my ASUS Pad Stewart Bryant (stbryant) stbry...@cisco.com wrote: Sent from my iPad On 6 Apr 2013, at 14:04, Abdussalam Baryun abdussalambar...@gmail.com wrote: If the date is special then thoes RFCs SHOULD be *historical*. Surely the correct requirement is : If the date is special then those RFCs MUST be *hysterical*. - Stewart
Re: On the tradition of I-D Acknowledgements sections
On Sun, 2013-03-24 at 22:23 -0400, Joel M. Halpern wrote: I think I at least partly disagree. The acknowledgements section of RFCs was not, and to the best of my knowledge is not, concerned with capturing the history of where specific changes or ideas came from. It ought to be concerned with giving credit to folks who made particularly large, but not authorship level, contributions to the document. +1 .. and such contributions may well be reviews that don't change the substance of the document or add new ideas but result in improvments to the expression of the ideas or catch mistakes. These can be just as vital as extra ideas to making a successful RFC. IMO it is vital that for reviewing to be successful it has to be 'ego-free'. The reviewer shouldn't be aiming to catch the authors out or push his/her prejudices into the document but rather to collectively improve the document. So 'ego-free' should mean that the reviewer is looking for a better document and not a 'puff' in the acknowledgements. Yes, it is nice to get an acknowledgement of your review work but I'm not going to go beat up the authors if I don't get it. In practice, the reviews that are perhaps least likely to be acknowledged are the ones which say 'I read it: it was well written and it looked good to me.' They are very nearly as much work as the ones that say 'It's broken because...'! As regards 'history': RFCs record 'state' and not history. That isn't to say that recording history in some other place than the fallible memories of participants and fragmented threads in mailing lists wouldn't be advantageous not least in avoiding wheels being reinvented and failures being repeated. But I have never been involved in a project that actually even tried to keep a 'design diary' or similar document. Probably, mea culpa sometimes! Whatever, it doesn't belong in the resulting RFC. Regards, Elwyn
Re: Please review draft-housley-rfc2050bis-00.txt
Hi, Russ. Two points: On Tue, 2013-03-19 at 22:30 -0500, David Farmer wrote: snip Rereading things again, I have another suggestion; 4) Split the Goals of the Internet registry system out of the Introduction. The Intro starts out talking about the document, its goals, and what is in scope and out of scope of the document. Then transitions to talking about the goals of the Internet registry system. I think the goals of the Internet registry system should be a separate section from the Introduction. And, the Introduction should be expanded to better describe the purpose of the document. I agree fully with this comment. The first para of s1 needs a rewrite and a little expansion to match up with the abstract to form a proper intro. The goals do belong in a separate section Also regarding the first para of s4: This contains some woolly hand-waving weasel words at the end: Over the years, the Internet Numbers Registry System has developed mechanisms by which the structures, policies, and processes of the Internet Numbers Registry System itself can evolve to meet the changing demands of the global Internet community. Further evolution of the Internet Numbers Registry System is expected to occur in an open, transparent, and broad multi-stakeholder manner. ^^^ Who are these stakeholders? Is this (just) the organisations named in the document (I think that would be ICANN/IANA, IETF, *IRs - a large number!) or is the community to be consulted? and governments? So do we have a view as to how all these people are to be informed that some evolution is needed? Regards, Elwyn
Re: IPR view (Re: Internet Draft Final Submission Cut-Off Today )
Submission allowed; publication postponed? /Elwyn On Thu, 2013-03-07 at 10:34 +0100, Carsten Bormann wrote: Oh, and one more data point: The Internet-Draft archive also functions as a timestamped signed public archival record of our inventions. (Which are often trivial, but triviality won't stop patenting of copycats, while a good priority more likely will.) This function is effectively suspended for six weeks a year. Grüße, Carsten PS.: (If that sounds like I'm contradicting myself that's only because we haven't found the right solution yet.) On Feb 27, 2013, at 19:49, Carsten Bormann c...@tzi.org wrote: On Feb 27, 2013, at 19:18, ned+i...@mauve.mrochek.com wrote: routing around obstacles It turns out for most people the easiest route around is submitting in time. That is actually what counts here: how does the rule influence the behavior of people. Chair hat: WORKSFORME. (And, if I could decide it, WONTFIX.) Grüße, Carsten
More Plugins for Firefox to do draft searches and draft/RFC HTML downloads
Hi.
Thanks to Dale for the new search plugins - useful.
I made these other ones that get RFCs and use the tools.ietf.org HTML
page to find sets of drafts from a few words. They were originally
published on the tools discuss list about 19 months ago.
Download the attachments into the searchplugins sub-directory of the
Firefox installation directory or your local profile
(~/.mozilla/firefox/X.default/searchplugins on Linux) and restart
Firefox. Its easy enough to customize the plugins if you want a specific
WG/RG because you are dealing with it all the time.
I'd like the searches to download the HTML or text etc to taste if the
search finds only one draft, but the 404 error handler doesn't deal with
extra parameters at the mome
Hope these might be useful.
Regards,
Elwyn
SearchPlugin xmlns=http://www.mozilla.org/2006/browser/search/;
ShortNameRFC HTML get (RFC ...)/ShortName
DescriptionIETF RFC Series Archive Search/Description
InputEncodingUTF-8/InputEncoding
Image width=16 height=16data:image/png;base64,iVBORw0KGgoNSUhEUgAAABAQCAMoLQ9TLHRFWHRDcmVhdGlvbiBUaW1lAFRodSAxOSBEZWMgMjAwMiAxNDozOToxOSArMDEwMAbxpfkHdElNRQfSDBULOgQfhKipCXBIWXMAAArwAAAK8AFCrDSYBGdBTUEAALGPC/xhBQAAAwBQTFRFMwAAZgAAmQAAzAAA/wAAADMAMzMAZjMAmTMAzDMA/zMAAGYAM2YAZmYAmWYAzGYA/2YAAJkAM5kAZpkAmZkAzJkA/5kAAMwAM8wAZswAmcwAzMwA/8wAAP8AM/8AZv8Amf8AzP8A//8zMwAzZgAzmQAzzAAz/wAzADMzMzMzZjMzmTMzzDMz/zMzAGYzM2YzZmYzmWYzzGYz/2YzAJkzM5kzZpkzmZkzzJkz/5kzAMwzM8wzZswzmcwzzMwz/8wzAP8zM/8zZv8zmf8zzP8z//8zAABmMwBmZgBmmQBmzABm/wBmADNmMzNmZjNmmTNmzDNm/zNmAGZmM2ZmZmZmmWZmzGZm/2ZmAJlmM5lmZplmmZlmzJlm/5lmAMxmM8xmZsxmmcxmzMxm/8xmAP9mM/9mZv9mmf9mzP9m//9mAACZMwCZZgCZmQCZzACZ/wCZADOZMzOZZjOZmTOZzDOZ/zOZAGaZM2aZZmaZmWaZzGaZ/2aZAJmZM5mZZpmZmZmZzJmZ/5mZAMyZM8yZZsyZmcyZzMyZ/8yZAP+ZM/+ZZv+Zmf+ZzP+Z//+ZAADMMwDMZgDMmQDMzADM/wDMADPMMzPMZjPMmTPMzDPM/zPMAGbMM2bMZmbMmWbMzGbM/2bMAJnMM5nMZpnMmZnMzJnM/5nMAMzMM8zMZszMmczMzMzM/8zMAP/MM//MZv/Mmf/MzP/M///MAAD/MwD/ZgD/mQD/zAD//wD/ADP/MzP/ZjP/mTP/zDP//zP/AGb/M2b/Zmb/mWb/zGb//2b/AJn/M5n/Zpn/mZn/zJn//5n/AMz/M8z/Zsz/mcz/zMz//8z/AP//M///Zv//mf//zP//3jnFswAAAFZJREFUeNptjoENACEIA91/ni7RCbrOQyGPGhGRnLW4dMUCQCkqxGwTxOGaBQFU6U2MwmD32EDL/yfs2zFlqXrs62NHPBRCDWV4RG/grGn2KNBrFDLEB5CVxULY70vUAElFTkSuQmCC/Image
Url type=text/html method=GET template=http://tools.ietf.org/html/{searchTerms};
/Url
SearchFormhttp://tools.ietf.org/id/SearchForm
/SearchPlugin
SearchPlugin xmlns=http://www.mozilla.org/2006/browser/search/;
ShortNameWG Draft (draft-ietf-...)/ShortName
DescriptionIETF Working Group Internet Draft Archive Search/Description
InputEncodingUTF-8/InputEncoding
Image width=16
Re: Appointment of a Transport Area Director
+1 to Mary's comments.. few words in line.. Elwyn Davies On Mon, 2013-03-04 at 09:11 -0600, Mary Barnes wrote: On Mon, Mar 4, 2013 at 7:39 AM, Eric Burger ebur...@standardstrack.com wrote: There is obviously no easy fix. If there was, we would have fixed it, obviously. What I find interesting is after saying there is nothing we can do, you go on to make a few concrete proposals, like bringing the directorates more into the process. It is thinking like that, how to do things different, that will get us out of the bind we have made for ourselves. Note that I am not married to the idea of expanding the role of directorates. I am married to the idea that we can think ourselves outside of the box. On Mar 4, 2013, at 8:07 AM, Eggert, Lars l...@netapp.com wrote: Hi, On Mar 4, 2013, at 13:18, Eric Burger ebur...@standardstrack.com wrote: I will say it again - the IETF is organized by us. Therefore, this situation is created by us. We have the power to fix it. We have to want to fix it. Saying there is nothing we can do because this is the way it is is the same as saying we do not WANT to fix it. what is the fix? The IETF is set up so that the top level leadership requires technical expertise. It is not only a management job. This is a key differentiator to other SDOs, and IMO it shows in the quality of the output we produce. The reason the RFCs are typically of very good quality is that the same eyeballs go over all documents before they go out. This creates a level of uniformity that is otherwise difficult to achieve. But it requires technical expertise on the top, and it requires a significant investment of time. [MB] Personally, I'm not at all seeing this concept of uniformity in terms of the output. I don't even see consistency amongst documents for specific WGs. We can't even agree how normative language should be used in documents. I've been a gen-art reviewer for 9.5 years and we don't even come close to producing consistent documents. I fully agree that there is significant value in the cross area reviews, in particular for security. But, I personally think that can happen as effectively at the directorate review as at the IESG level of review. [/MB] [EBD] I have also been a gen-art reviewer for about a long as Mary and I totally agree that consistency is not what we get, especially on the quality front. However really the only consistencies that are really vital are comprehensibility and technical quality. Variations in style make life a little more entertaining and I would prefer not to resort to some sort of uniform legalese - in any case, not all drafts are talking about the same sort of thing. And, yes, multiple reviews with different points of view do help. [/EBD] I don't see how we can maintain the quality of our output if we turn the AD position into a management job. [MB] I don't think anyone is suggesting to turn it into just a management job. It still requires someone with significant technical expertise in other areas. I don't think there's anyone hanging around in IETF that's being considered for IESG positions that doesn't have significant technical expertise in some areas. This problem has been around since I was Nomcom chair, so it seems that there is no easy solution - would there be a way to split the role, so that you do have a solid technical advisor, they just have to bother with reviewing documents unless they are brought to their attention and they don't have to worry about managing the day to day activities of WGs. I would be curious to know the typically time split between these two tasks for the average AD. [/MB] [EBD] Maybe the difference between what I do and the AD's reviewing job is context. Mine is diffuse - I have a general idea what is going on and enough background to recognize when something might be broken; I also have enough understanding to recognize when a novice would get lost in a document that has its head down in the sands of jargon and groupthink. We call ADs AREA Directors presumably because they have the context of their area in mind when reviewing; I don't. Hopefully, an AD is not seeing a doc that comes to the IESG for the very first time because s/he has got some idea of what is going on in the WG or has sponsored a doc. Hopefully (again) this gives the AD some context in which to view the document, know its importance overall, interpret comments from others and home in on key areas where they anticipate there might be concerns; so there is synergy between the managemnt and technical reviewing tasks. Area directorates probably fall in between on the context scale. But ultimately the AD is called upon to make one or more judgment calls both as regards documents and the performance of WGs. I would be extremely unhappy if these calls were purely management exercises - they need a combination of technical nous, management
Gen-art last call review of draft-ietf-opsawg-oam-overview-08.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-opsawg-oam-overview-08.txt Reviewer: Elwyn Davies Review Date: 22 Jan 2013 IETF LC End Date:25 Jan 2013 IESG Telechat date: (if known) - Summary: In my opinion, this draft has serious issues as described below. Major issues: General 1: Title vs Abstract vs Section 1 vs actual content: Here in the UK a well-known brand of varnishes and wood preservative paints uses the slogan 'Does what it says on the tin!'. If my understanding and the write-up in RFC 6491, OAM covers a whole lot more than the coverage of the specific mechanisms discussed in this document .. and there are various other mechanisms such as SNMP and Netconf that support the OAM constellation. I would take the view that this document certainly does not 'do what it says on the tin'. Accordingly I take issue with the title as it doesn't provide a total overview of OAM mechanisms; the abstract closes down the scope of OAM as compared with RFC 6491 and s1 restricts it even more - and certainly does not summarize all the OAM tools and mechanisms defined in the IETF. The last para of s1 claims that 'management aspects are outside the scope of this document' - if this is really saying that this 'overview' of OAM skips the whole M aspect of OAM then I'm afraid the document is badly misnamed. And it significantly reduces the value of the work. General (2): The intended purpose of this document: Back in 2011 Stewart Bryant summarized a review of a previous version of this document from the routing directorate (https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/history/ entry dated 2011-08-10 referring to version 05 of the document). IMO the initial section of that review regarding the audience of this document was well targeted and *has not been fixed*. If this is intended as an introductory overview for people wishing to see what OAM is about in the IETF then it needs further introductory text and some background. It should also state what its target audience actually is. General (3): I don't know if Scott Bradner has actually produced a proto shpeherd write up, but I would be intrigued to know the level of concensus behind this document. In particular the tool classification in s1.1 and terminology in s2 (particularly s2.2.2) is that used exclusively in the MPLS-TP work in the IETF which is derived from the 802.1ag terminology. The terminology is presented as if it is common to OAM work across the IETF. Does the IETF management community at large concur with this expansion of the applicability of the terminology set based on 'Management Domains' etc? General (4): As an overview, I think it would be advisable to point out that one reason for the multiplicity of tools is that they support at least four different data plane technologies (native IP, vanilla MPLS, MPLS-TP and PWE) and note that in several cases the data plane technologies rely on distinct (IP-based) management channels to allow the information gleaned by the operations in the the data plane to be reported back to the application that originated the operation. Minor (or at least less major) issues: s1, para1: For consistency with the abstract, s1.1 .. and because I'd expect OAM to handle it as well ... OAM deals with performance monitoring and statistics gathering as well as dealing with degradation. s1.1: The section is entitled building blocks but actually only mentions one block, i.e., the OAM protocol. Presumably this section really ought to say something about the applications and device drivers that have to instantiated in the MPs. In particular as introduction to the text in the following section it should say something about classifying applications into continuously running or proactive monitoring and on-demand applications (since the latter are introduced without any definition in the next section.) s2.2.2/3: I am not familiar with 802.1 management issues and I was rather confused by the logical status of MIPs . The text here seems to indicate that they are intermediate and generally don't terminate messages but then says in s2.2.3 that messages are 'destined to' MIPs. Looking for some additional understanding, I fetched up at Wikipedia (now there's a surprise) http://en.wikipedia.org/wiki/IEEE_802.1ag. This page mentions the concept of maintenance domains and the explanation of MIPs as internal points in the domain that generally forward messages within the domain whereas end points (MEPs) are effectively on the domain boundary. This makes a whole lot more sense and seemed to be a rather better set of term definitions than we have in this draft. I noticed eventually that the term Management Domain (MD) had appeared in the first line of s1.1 but does
Re: Idea for a process experiment to reward running code...
Hi. On Mon, 2012-12-03 at 11:02 +, Brian E Carpenter wrote: On 03/12/2012 06:01, Martin J. Dürst wrote: One of the advantages of a standards organization such as the IETF is cross-concern review. For the IETF, one very strong cross-concern is security. Another one (also for my personally) is internationalization. Another, more vague one, is general architecture. Early running code is very often (not always) characterized by the fact that such cross-concerns are actively or passively ignored. An excellent point. The fact that a hack works, and can be implemented, does not alter the fact that it's a hack. This is the sort of thing that cross-area review is supposed to look for. As a gen-art reviewer, I am sometimes surprised by what gets through to Last Call in the regular process - if the whole review process is squeezed down to a couple of weeks, we will definitely miss cross-area issues. I also have the experience as a gen-art reviewer of seeing some pretty awful pieces of work making through even to IESG review. However, I don't think that a short last call cycle need necessarily compromise cross-area review. There has always been the possibility for authors or wg chairs to request a early gen-art review with a view to checking out whether something is in good shape cross-area and for non-specialists. This facility is not much used (I think I have done 3 in 8 years on the gen-art team) but it is there, and I guess the team could cope with a few more since it doesn't drastically alter the total workload. So it would be entirely possible for a draft that might be fast-tracked to get some early review. Given that there is also open source code, reviewers have the chance to take a look at that and see the degree of hackiness involved. So I'd be for trying the experiment - and asking some cross-area reviewers to take an early sniff. Regards, Elwyn Encouraging running code is a Good Thing. Publishing sloppy specifications is a Bad Thing. The Interop show network used to be a Very Good Thing. We've lost that, though I was delighted to see some actual running code at Bits-n-Bytes in Atlanta. More please. Maybe a prize for Best Demo? Brian I had a look at your draft and checked for security and internationalization, but only found the former, and not not in a discussion about how this proposal would make sure that cross-concerns are adequately addressed. Regards, Martin. On 2012/12/02 5:12, Stephen Farrell wrote: Hi all, I've just posted an idea [1] for a small process improvement. If it doesn't seem crazy I'll try pursue it with the IESG as an RFC 3933 process experiment. If its universally hated then that's fine, it can die. The IESG have seen (more-or-less) this already but it hasn't be discussed, so this is just a proposal from me and has no official status whatsoever. Any comments, suggestions or better ideas are very welcome. Feel free to send me comments off list for now, or on this list I guess. If there's loads of email (always possible, this being a process thing;-) we can move to some other list. Regards, Stephen. [1] http://tools.ietf.org/id/draft-farrell-ft
Re: Idea for a process experiment to reward running code...
On Mon, 2012-12-03 at 14:28 +, Stephen Farrell wrote: On 12/03/2012 02:25 PM, Barry Leiba wrote: Running code, when it's an organic part of the document development, is undoubtedly a good thing -- it doesn't make everything right, but, yes, it does do *some* spec validation and probably does help spec quality. Fully agree. And this kind of experiment may encourage that good thing some more. Or not. We'll not see if we don't try. We may see if we do try. I think its worth trying. (That's fairly obvious I guess:-) S. Another thing which it might help with is weeding out gratuitous proliferation of options. Regards, Elwyn
Re: Idea for a process experiment to reward running code...
Barry responded... On Mon, 2012-12-03 at 09:50 -0500, Barry Leiba wrote: Elwyn says... However, I don't think that a short last call cycle need necessarily compromise cross-area review. There has always been the possibility for authors or wg chairs to request a early gen-art review with a view to checking out whether something is in good shape cross-area and for non-specialists. This facility is not much used (I think I have done 3 in 8 years on the gen-art team) but it is there, and I guess the team could cope with a few more since it doesn't drastically alter the total workload. So it would be entirely possible for a draft that might be fast-tracked to get some early review. Do you really think it's likely that a chair who's trying to fast-track a document will likely go out asking for early GenART, SecDir, AppDir, and OpsDir reviews? A few do already. But seriously, if the wg chair(s) actually have an interest in the technology and feel there is a valid reason for getting something decent out into the world quickly then they could well be motivated to do just that. If our wg chairs are really just bureaucratic process minders then it's time we found some different ones, but I don't think they are. Maybe this is just a plea for a bit more parallel processing and a few less silos. /Elwyn
Re: [Gen-art] Gen-art last call review of draft-ietf-codec-opus-12.txt (completed)
Hi, Jean-Marc and co-authors On Thu, 2012-05-17 at 12:49 -0400, Jean-Marc Valin wrote: Hi Elwyn, We're submitted a -14 draft to address your comments. Again, see the response to each of these issues in the attached document. I think we are done. Thanks once again for the rapid response. Regards, Elwyn PS I still prefer octets. /E Thanks again, Jean-Marc On 12-05-16 05:26 PM, Elwyn Davies wrote: Hi, Jean-Marc. ... and thanks for the super-quick response! You have been quite busy. I have had a look through the new draft and I think the additions help considerably with comprehension for the naive (and to give new implementers a way in.)
Re: [Gen-art] Gen-art last call review of draft-ietf-codec-opus-12.txt (completed)
Hi, Jean-Marc. ... and thanks for the super-quick response! You have been quite busy. I have had a look through the new draft and I think the additions help considerably with comprehension for the naive (and to give new implementers a way in.) I'll leave you to negotiate with the RFC Editor over the Wikipaedia references. To quote the RFC Style guide http://www.rfc-editor.org/rfc-style-guide/rfc-style Section 4.8, item (x) References, last section: URLs and DNS names in RFCs The use of URLs in RFCs is discouraged, because many URLs are not stable references. Exceptions may be made for normative references in those cases where the URL is demonstrably the most stable reference available. References to long-lived files on ietf.org and rfc-editor.org are generally acceptable. They are certainly convenient *as long as they remain in place and aren't corrupted*. I found a couple of trivial editorial nits in the changes: s4.3.3 (in the added text): The CELT layer, however, can adapt over a very wide range of rates, and thus has a large number of codebooks sizes s/codebooks/codebook/ s4.3.3, para after Table 57: s?the maximums in bit/sample are precomputed?the maximums in bits/sample are precomputed? Also suggest: s4.3: Add reference for Bark scale: Zwicker, E. (1961), Subdivision of the audible frequency range into critical bands, The Journal of the Acoustical Society of America, 33, Feb., 1961. A few responses in line below (agreed pieces elided): Regards, Elwyn Davies On Tue, 2012-05-15 at 20:33 -0400, Jean-Marc Valin wrote: Hi Elwyn, Thanks for the very thorough review. We've addressed your issues and submitted draft version -13. See our response to each of the issues you raised (aggregated from all the authors) in the attached document. Thanks very much to all the authors. Cheers, Jean-Marc Elwyn Davies wrote: Major issues: Can we accept the code as normative? If not how do we proceed? The issue with code being normative was specifically addressed in the guidelines document for this WG (RFC 6569). Yes. I failed to read this although Robert Sparks did point out to me that the code was normative - but he didn't think he said this was agreed in advance (or maybe I didn't understand what he was saying). To be honest I would like to have had the time to tie the text to the code but realistically that is several weeks or even months work to do it properly - without that I feel that I have only done half a job. I may decide that it interests me enough to have a superficial go next week but no promises! Minor issues: Contrast between decoder descriptions of LP part and CELT part: The SILK descriptions go into gory detail on the values used in lots of tables, etc., whereas the CELT part has a very limited treatment of the numeric values used (assuming reliance on finding the values in the reference implementation, either explictly or implicitly). There are things to be said for both techniques. I was wondering (while reading the SILK description) if the authors have any means of automatically generating the tables from the code in the SILK part (or vice versa) to avoid double maintenance. On the other hand, there are pieces of the CELT decoder description (especially in s4.3.3 where knowing numbers of bands, etc.) where some actual numbers would help comprehension. We have made many changes to section 4.3 (and 4.3.3 specifically) to address the specific issues below. As for the tables, they are not generated automatically. I think this is addressed satisfactorily now. There is still some difference but it is much reduced and not so glaring now. The addition of the band tables really helps. s2 (and more generally): The splitting of the signal in the frequency domain into signal (components?) below and above 8kHz presumably requires that the signal is subjected to a Discrete Fourier Transform to allow the signal to be split. I think sometging is needed in s2 to explain how this is managed (or if I don't understand, to explain why it isn't necessary). No DFT is used. The lower band is obtained through resampling (which is already described) and the higher band is obtained by not coding the lower band with CELT (the text says that CELT starts at band 17 in hybrid mode). The explanation was reworded to make this as clear as possible at this point in the text. [I thought I had reworded this comment in the 2nd version to talk about MDCT but no matter]. Yes, para 5 of s2 does say that the bands are discarded. I think it would useful to have a concrete statement in the new text added to s4.3 that bands 0 to 16 are discarded in hybrid mode (thereby making the 17 in the band boost section more obvious) [There is a comment below that you have added some text about band 17
Re: Gen-art last call review of draft-ietf-codec-opus-12.txt (completed)
On Mon, 2012-05-14 at 17:08 -0600, Cullen Jennings wrote: Thank you kindly for the detailed review. More inline ... On May 14, 2012, at 9:06 AM, Elwyn Davies wrote: Summary: Before offering some views on the document, let me say that this piece of work seems to be a tour de force on behalf of its developers. It is certainly one of the (if not the) most technically complex pieces of work that has been presented to the IETF, And I would like to say thank you for the detailed review - having read the whole draft several times, I know that ones eyes can start to glaze over on what seems like something almost as long as the NFS spec ... so thanks for the review. Not sure I would say 'it was my pleasure' but it certainly taught me a thing or two! I did want to comment on the one major issues Major issues: Can we accept the code as normative? If not how do we proceed? RFC 6569 says that the code needs to be the normative specification so I think this issues is pretty much resolved by that RFC. As a bit of irrelevant history - this topic was discussed at various stages. If was discussed in the chartering process - draft-valin-codec-guidelines referred to by the charter said code would be normative. I don't mean by this that the charter said the code had to be normative but just that this conversation goes back to before the WG was formed. It was later discussed in the WG and resulted in WG consensus to having the code as normative. Just as background on a few of the reasons that this was decided this way, many people felt that the spec would be much longer, and much harder to implement or review if the text was normative. Code is a very compact representation of what happens on boundary edge conditions and eliminates many types of misinterpretations. I do understand normative code introduces other types of issues but it is a fairly common practice in specifying codecs to use normative code. Cullen Codec Co-Chair I don't have a problem with this in principle: however as a reviewer I get this nagging feeling that on a few days acquaintance, its impossible to demonstrate that the text accurately, albeit non-normatively describes the code. And that makes me feel I have done a half job. However, I also know that starting from scratch it would take me several months to get anywhere near an accurate view (I know from considerable experience with the DTN2 reference implementation and years ago the source code of yacc - now that ages me!) If the wg, doc shepherd and the IESG are happy that the mapping is near enough, so be it. And, sorry, I didn't look at RFC 6569 during my review.. probably shoyuld have done. Regards, Elwyn
Gen-art last call review of draft-ietf-codec-opus-12.txt (completed)
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-codec-opus-12.txt Reviewer: Elwyn Davies Review Date: 14 May 2012 (completed) IETF LC End Date: 10 May 2012 IESG Telechat date: (if known) - Summary: Before offering some views on the document, let me say that this piece of work seems to be a tour de force on behalf of its developers. It is certainly one of the (if not the) most technically complex pieces of work that has been presented to the IETF, and is far more mathematically complex and rigorous than our usual run of standards. It is also perhaps a vindication of the rough concensus and running code philosophy. So congratulations to the authors and the companies that have supported this work. But back to the review I came to this review with a very outdated view of what goes on inside codecs, so it was rather a shock to the system. Taking that into account, I think that some additional high level, up front description of the two parts (SILK and CELT) and the range encoding system would make it easier for future (naive) readers and potential implementers to understand what is going on. For example, after struggling with the description of CELT in the decoder (s4.3) I found that going off and reading the slides on CELT presented at IETF 79 helped considerably. Such additions might also help future dissemination of the technique by giving potential users a quick overview. It would also make it easier to justify the decision to postpone the high level (and highly mathematical/technical) view to section 5 after the detailed description of the decoder. I also found that the descriptions of the SILK and CELT decoders appeared to be written with a different perspective (see detailed comments) doubtless by different authors. This is not ideal and, despite the expected further increase in page count, some additional text in s4.3 seems desirable. By far the most difficult to parse section is 4.3.3 talking about bit allocation in CELT. Despite considerable study, I didn't feel I had really got to grips with how this worked. An example might help. Finally, the most contentious aspect of this document is the requirement to treat the code as normative. There are just over 30,000 physical lines of code and I haven't checked them hardly at all. Slocount reckons this represents 7.14 man years of effort. As with the document, there is a discrepancy between CELT and SILK with the latter code being more heavily commented, especially as regards routine parameters. A proper validation of the claim that the code implements the description would take several weeks of time: I guess that we have to take the document shepherd's assurances on this. One issue is that both code and document are pretty much saturated with what we used to call 'magic numbers'. Although these are explained in the document, it does not appear that this is always the case in the code. I would also be happier if the code contained Doxygen (or similar) dcoumentation statements for all routines (rather than just the API). So overall, the work is something that ought to be standardized but the document needs further work - not quite ready for the IESG. Major issues: Can we accept the code as normative? If not how do we proceed? Minor issues: Contrast between decoder descriptions of LP part and CELT part: The SILK descriptions go into gory detail on the values used in lots of tables, etc., whereas the CELT part has a very limited treatment of the numeric values used (assuming reliance on finding the values in the reference implementation, either explictly or implicitly). There are things to be said for both techniques. I was wondering (while reading the SILK description) if the authors have any means of automatically generating the tables from the code in the SILK part (or vice versa) to avoid double maintenance. On the other hand, there are pieces of the CELT decoder description (especially in s4.3.3 where knowing numbers of bands, etc.) where some actual numbers would help comprehension. s2 (and more generally): The splitting of the signal in the frequency domain into signal (components?) below and above 8kHz in the hybrid case presumably requires that the output of the CELT encoder is windowed so that only one of encoders gnerates output below 8kHZ. I think something is needed in s2 to explain how this is managed (presumably to do with energy bands?). I didn't find anything in s5 about what has to be done for the encoder when running in hybrid mode which surprised me somewhat. s4.1: Despite having found a copy of the range coding paper and tried to read it, I found the description of range coding opaque (there are some more words later in s5 but this is a bit late for understanding the decoder
Re: watersprings.org archive of expired Internet Drafts
Hi. I don't know who was responsible for the Watersprings archive, but I think we should send whoever it was a vote of thanks for providing this (free) resource during all the years that the IETF was not able or willing to provide it. So THANK YOU! It was extremely useful. But I am now quite happy with the IETF draft archive and I have a couple of customized Firefox search entries that minimize the amount of typing needed. Regards, Elwyn On 10/10/2011 10:23, t.petch wrote: Original Message - From: Julian Reschkejulian.resc...@gmx.de To: t.petchdaedu...@btconnect.com Cc: Frank Ellermannhmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com;ietf@ ietf.org Sent: Saturday, October 08, 2011 3:07 PM On 2011-10-08 09:20, t.petch wrote: If I'm looking for an internet draft where I only know parts of the name I usually use a search engine; that's what they are for. With the current flavour of the IETF web site, I usually go via charters - WG - I-D list and then find 103 I-Ds in an order I cannot divine, give up and accept that I will have to type in d r a f t - i e t f - w g etc etc. Another waste of my time along with gif download, xml processing etc oh, did I mention all the javascripts that try to out think me and get in the way? mutter mutter ... What does XML have to do with all of this? Julian On a thread on this list some time ago, IANA reported progress in converting their web site to XML and at the same time, apologised for how long it now takes to access the Port Registry. Having accessed it - a good chance to complete The Times crossword! - I found an XML file in excess of 1Mbyte on my workstation. Making a wild leap of imagination, I guessed that the time it took to access the web page was due, at least in part, to these multi-megagbytes of XML, but I could be wrong. Tom Petch Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- The Cambridge Oxfam Walk 2011 has happened. There will be another walk next year. In the meantime please donate to Oxfam. For more information, see http://www.oxfam.org.uk/get_involved/fundraise/walk/ and follow us on Twitter at http://twitter.com/CambOxfamWalk. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: watersprings.org archive of expired Internet Drafts
On 10/10/2011 20:25, Andrew G. Malis wrote: Very nice, thanks!! On Mon, Oct 10, 2011 at 2:46 PM, Doug Bartondo...@dougbarton.us wrote: On 10/10/2011 07:17, Elwyn Davies wrote: But I am now quite happy with the IETF draft archive and I have a couple of customized Firefox search entries that minimize the amount of typing needed. https://addons.mozilla.org/en-US/firefox/addon/ietf-doc-fetch-73306/ You can type in an RFC number, or all/part of an I-D name. There are five more specific search/get plugins in an email I just sent to the tools discuss mailing list. It should be in the archive real soon now: https://www.ietf.org/mailman/listinfo/tools-discuss /Elwyn -- The Cambridge Oxfam Walk 2011 has happened. There will be another walk next year. In the meantime please donate to Oxfam. For more information, see http://www.oxfam.org.uk/get_involved/fundraise/walk/ and follow us on Twitter at http://twitter.com/CambOxfamWalk. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART review of draft-oreirdan-mody-bot-remediation-16
Thanks Miguel. Regards, Elwyn On Wed, 2011-10-05 at 15:40 +0200, Miguel A. Garcia wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Please resolve these comments along with any other Last Call comments you may receive. Document: draft-oreirdan-mody-bot-remediation-16 Reviewer: Miguel Garcia miguel.a.gar...@ericsson.com Review Date: 2011-10-05 IETF LC End Date: 2011-10-21 IESG Telechat date: Summary: The document is ready for publication as an Informational RFC. /Miguel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Grey Beards (was [81all] Quick Meeting Survey)
Time for the facial hair standard and ensuring that there is a proper three stage progression from provisional salt and pepper to full blown white out. /Elwyn Eric Burger wrote: You all are just bragging you still have hair :-( On Sep 21, 2011, at 12:55 AM, Melinda Shore wrote: On 9/20/11 6:26 PM, Ronald Bonica wrote: This reminds me that it has been a while since we took the last IETF grey beard photo. A few more of us have gone grey since then. Maybe we should plan on another photo to be taken after the next Administrative Plenary. Beardless, but back when I started participating in the IETF my hair was nearly black. Now I've gone completely grey. Not trying to imply causality, of course. Count me in. Melinda ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pcn-cl-edge-behaviour-08 Reviewer: Elwyn Davies Review Date: 10 June 2011 IETF LC End Date: 10 June 2011 IESG Telechat date: (if known) - Summary: In my opinion, there are a number of areas that need significant work and at least one open issue (the stability question from s3.3.1) that needs to be addressed before this document is ready for the IESG. Major issues: The draft contains partial definitions of two control protocols (egress - decision point; decision point - ingress). It does not make it clear whether the reader is expected to get full definitions of these protocols here or whether there will be another document that specifies these protocols completely. As is stands one could build the protocols and pretty much guarantee that they would not be interoperable with other implementations since message formats are not included although high level specs are. The document needs to be much clearer about what is expected to happen here. Use of EXP codepoint: My understanding of what is said in RFC 5696 is that EXP is supposed to be left for other (non=PCN) systems to use. This draft uses it. Is this sensible? Is this whole draft experimental really? s3.3.1: [CL-specific] The outcome of the comparison is not very sensitive to the value of the CLE-limit in practice, because when threshold- marking occurs it tends to persist long enough that threshold- marked traffic becomes a large proportion of the received traffic in a given interval. This statement worries me. It sounds like a characteristic of an unstable system. If the value is that non-critical why are we bothering? Minor issues: s1.1: definition of PCN-Traffic etc: The same network will carry traffic of other Diffserv BAs. Just to be sure: Does this or does this not imply that *all* traffic in a PCN network must have a non-empty DSCP marking, i.e. that *all* traffic must be attached to some specific Diffserv BA? This should be clarified whichever is true. s1.1: T-fail: I notice from s3.1 that PCN-ingress nodes also have to make reports on request. Should T-fail or some other timer apply to non-return of info from ingress points? What would a (probably non-colocated) decision point do if it lost contact with the ingress? s2/s3.2.1: The use of PM and EXP codepoints for ThM and ETM appear to be reversed in these two sections!! Which way round is intended? s3.2.1/s3.2.2: Neither section mentions T-meas but I assume that this is supposed to be (either or both) the sampling period in the egress node or the period between reports. It is unclear if they are allowed to be different and if they are which one is T-meas. However s3.2.3 appears to imply that T-meas is probably the time between reports. This all needs to be much clearer. s3.2.1/3.2.2: In s3.2.2, para 2: If so configured (e.g., because multipath routing is being used, as explained in the previous section), the PCN-egress- node MUST also report the set of flow identifiers of PCN-flows for which excess-traffic-marking was observed in the most recent measurement interval. This is a requirement for a protocol that you may or may not be defining. Confusing. s3.2.3/s3.2.2: The first paragraph of s3.2.3 suggests that the report from an egress may not always contain the calculated value of the CLE, but s3.2.2 has a MUST for the report to contain this value. Consistency!!! s6: The potential introduction of a centralized decision point appears to provide additional attack points beyond the architecture in RFC 5559. It appears to me that the requests for information about specific flows to the ingress are ighly vulnerable as they (probably) contain all the information needed to craft a DoS attack on the flow. Nits/editorial comments: General: Consistency of naming for timing paramters t-meas/T-meas, etc. s1.1: I think it would be worth reproducing the CL-specific definitions: PCN-threshold-rate and threshold-marked since they are specific. s1.1: Congestion level estimate (CLE) A value derived from the measurement of PCN-packets received at a PCN-egress-node for a given ingress-egress-aggregate, representing the ratio of marked to total PCN-traffic (measured in octets) ^ ^^ received over a short period. The ratio is (hopefully) dimensionless. Maybe '(each measured in octets)' ? s2: the PCN-domain satisfies the conditions specified in [RFC5696]; This may be a bit pedantic but I am not sure that RFC 5696 actually sets out conditions for the domain. It sets out rules for encoding markings and allowed transitions. Maybe s/conditions/packet markings and allowed
Gen-art review of draft-lear-iana-timezone-database-03
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-lear-iana-timezone-database-01.txt Reviewer: Elwyn Davies Review Date: 22 April 2011 IETF LC End Date: 9 May 2011 IESG Telechat date: 12 May 2011 Summary: Almost ready for the IESG. This is my second review of the document. I suggested in the previous review that it might make life easier, particularly if an appeal was ever entered, if the document didn't use the RFC 5226 Designated Expert mechanism but defined the role separately. This hasn't happened but the distinction is now clearer. To make it quite clear I would be inclined to add 'except as regards appeals against decisions of the Designated Expert (see Section 5)' after [RFC5226] in the definition of TZ Coordinator in Section 2. Otherwise there are a couple of editorial nits. . Nits/Editorial: s3: s/policy policy/policy/ (repeated word) s8, first para: s/filling/filling the role/ (maybe 'post') s8, last para: s/TZ Coordinators/TZ Coordinator/ s10: s/Elwin/Elwyn/ (thanks for the ack!) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-lear-iana-timezone-database-01
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-lear-iana-timezone-database-01.txt Reviewer: Elwyn Davies Review Date: 11 January 2010 IETF LC End Date: 11 January 2011 IESG Telechat date: (if known) Summary: This document is not quite ready for the IESG. The appeals process (if there is to be one) needs to clarified as it currently points indirectly to a hole in RFC 5226. As explained below, I have a feeling that it would be wise to avoid tying the processes in this document to the Designated Expert processes in RFC 5226 despite the similarities. Making it clear what does apply and what doesn't is probably more work than doing it from scratch in this document, especially given the hole in RFC 5226. Major(ish) issue: s4: As RFC-5226 states, the IESG is not a normal avenue for appeals of specific decisions of the coordinator, but rather a last resort when a coordinator is thought not to be functioning in an appropriate way. I think the draft should make it explicit that it is referring to the 'Designated Expert' sections in RFC 5226 here if it continues to reference RFC 5226 - although there is a clear relationship with Designated Experts, the differences between the selection process and the operations of the TZ Coordinator and generic Deisgnated Experts may mean that citing RFC 5226 might lead to legalistic disputes about which set of rules applies. Also, I am unable to find statements in RFC 5226 backing up the sentence above. Regrettably, RFC 5226 appears effectively to have a 'dsngling reference' in this area. Section 3.2, para 3 of RFC 5226 points at Section 5.2 which (allegedly) discusses 'disputes and appeals in more detail'. However s5.2 is titled 'Updating Registrations' and says nothing about appeals and disputes. Section 7 of RFC 5226 covers appeals of IANA decisions but says nothing specific about appealing designated expert rulings. I think this area may need a little more work. Overall, my inclination would be to make this a standalone document that does not try to partially modify the RFC 5226 Designated Expert process and operations. Appeals... *sigh*. Minor Issue: s3, para 3: Is it intended that that the supporting info should also be signed? If so the order of the phrases should be reversed. Nits/Editorial: s3: 'tar files' is jargon. s/tar files/archive files/ maybe adding in the format used by the 'tar' program. s4, last para: s/may/MAY/ s4, last para: 'OR MORE' - this isn't RFC 2119 language - is there any real need for capitalization? s5: The three instances of 'shall' ought to to be RFC 2119 terms: s/No change shall be made to licenses, where they exist./Licenses, where they exist SHALL NOT be changed./ s/IANA shall allow for the downloading of this reference code. The reference implementation shall be distributed/IANA SHALL allow for the downloading of this reference code. The reference implementation SHALL be distributed.../ s7: Arguably the various 'will's and 'may' in the later part of the section (from 'The IANA will provide' onwards) should be capitalised as RFC 2119 requirements: s/will/SHALL/ (5 places) and s/may/MAY/. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Question about Prague
On Fri, 2010-12-31 at 12:52 -0500, Marshall Eubanks wrote: On Dec 31, 2010, at 1:41 AM, Fred Baker wrote: On Dec 30, 2010, at 1:09 PM, Robin Uyeshiro wrote: The GPS in the rental car (rented in Munich) did not have the street information for Prague. It's not unusual, or at least it wasn't in 1997, for German rental agencies to not permit driving to the Czech Republic. As stated, my information is dated. The point is - check your contract. Before the Czech lands entered the EU (2004) that was very common, and very strict. (In 1999 I was almost arrested for trying to drive my Hertz car to the duty-free shop at the border crossing in Linz, Austria - by the Austrians! - because my rental contract didn't allow for the Czech Republic.) Now, you should tell your rental agency where you are going, but the last time I rented a car and drove to Prague, we didn't have any issues at all. There shouldn't even be a border post any more (since December 2007, the Czech Republic has been part of the Schengen area). Regards Marshall Driving into the Czech Republic shouldn't be a problem BUT you do have to tell the rental agency in advance and they will make a supplementary charge per day for the whole contract (not just the days you are out of Germany) if my recent experience is anything to go by (hire in Austria, drive to Slovenia). Its not particularly cheap either. Regards, Elwyn ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-art LC review of draft-cheshire-dnsext-nbp-09.txt
On Tue, 2010-12-14 at 18:19 -0800, Stuart Cheshire wrote: On 23 Nov 2010, at 7:15 AM, Elwyn Davies wrote: Summary: This document has at least one open issue that I believe needs fixing, either by altering the scope of the applicability of the solution or fixing the requirements. The requirements envisage a protocol that could be used in an enterprise environment but it does not address issues of visibility and accessibility. The document describes AppleTalk NBP, and what would be required in an IP-based equivalent. It does not claim to document all possible requirements of all possible service discovery protocols. The second sentence is certainly true. My comments do not seek ocean boiling. OTOH the document seeks to be not just an equivalent for Appletalk NBP but a specifically zero-configuration related service discovery protocol running over IP and explicitly targeting enterprise as well as (generally simpler) domestic type environments. Not being an enterprise network manager these days, I don't know what their hot buttons are in respect of service visibility but I do know that controlling visibility may be a factor. This issue is clearly related to the security requirements that have been discussed elsewhere but differs from the authentication and general authorization aspects that have been the focus there. I believe that there needs to be discussion of how the service discovery can be controlled so that individual users/machines are only informed of services that they might be allowed to use. The document describes AppleTalk NBP, and what would be required in an IP-based equivalent. AppleTalk NBP would find you (for example) all file servers on the network, not all file servers for which you know the password. We do not believe it is feasible in general to tie service discovery to access control. Nor is it useful: Discovering there's a printer for which you do know the password allows you to ask someone for the password. Discovering only resources to which you already have access (and therefore probably already know about) is significantly less useful. A paranoid (but literate) network manager will ask 'useful to whom'? Being able to determine all the resources available on the network with limited authorisation may not be seen as the most desirable situation. But I leave it to those with more current experience in this area to determine whether this is a genuine hole in the requirements. Regards, Elwyn Nits: [refreshingly free of nits!] The only comment might be that a pointer to some publically available definition or discussion of the existing Appletalk NBP miight be helpful if such a thing exists. There is not, which is why I wrote this document. Also idnits suggests that RFC 2462 should be replaced by RFC4862 which obsoleted it. Fixed. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-csi-send-name-type-registry-03
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. Document:draft-ietf-csi-send-name-type-registry-03.txt Reviewer: Elwyn Davies Review Date: 14 May 2010 IETF LC End Date: 14 May 2010 IESG Telechat date: (if known) - Summary: Probably not ready. There seems to be a conflict or confusion between the prescriptive specification of a single algorithm for how the Subject Key Identifier has to be created in this document and the permissive specification in RFC 5280 that allows any suitable algorithm. Either this specification will only deal with certificates that use the chosen SHA-1 hash or this specification is unnecessarily restrictive. There are also a a few (related) minor issues and nits. Major issues: s3/s3.1: There seems to be some confusion here. Section 4.2.1.2 of RFC 5280 does not specify a unique method for encoding the Subject Key Identifier extension and there doesn't appear to be any method of finding out what method was (allegedly) used to generate the Subject Key Identifier. S3 specifies that the SEND TA option has to carry the Key identifier in a specific one of those forms (#1 in RFC 5280). S3.1 specifies that the TA option carries the value from the SKI extension (without knowing whether that field is the SHA-1 form or some other). It appears that this document is placing a restriction on the algorithm used to generate the SKI extension value, but without saying this explicitly. This all seems a bit of a mess.. or am I missing something? Presumably the reason for the DER-encoding cruft is to facilitate simple comparison. Minor issues: s3/s3.1: Is the 'Key Identifier' described here sent as the value of the 'Name' field in the TA option? If so, say so. Otherwise explain what is in the Name field in this case and where the Key Identifier fits in. s3: Needs a reference to specify how to do DER-encoding of ASN.1 (and DER needs expanding). Nits/editorial comments: Abstract: s/This document request to IANA/This document is a request to IANA for the/ s2, para 1: s/to certify a router authority/to certify a router's authority/. s/for NDP/for the NDP/, s/This document request to IANA/This document is a request to IANA for the/ s2, para 2: s/the certificates are declared/the certificates ia declared/ s3: It would be clearer if the line starting '3 SHA-1' was indented a bit and the description separated so that it doesn't sit under the 'Name Type' header. Something like: Name TypeDescription 3SHA-1 Subject Key Identifier (SKI) s4, last para: s/is through/require/; there should be a reference to RFC 5226. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[Gen-art] Gen-art review of draft-ietf-ipsecme-ikev2bis-08.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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipsecme-ikev2bis-10.txt Reviewer: Elwyn Davies Review Date: 4 May 2010 IETF LC End Date: 18 March 2010 IESG Telechat date: 6 May 2010 Summary: When I reviewed this document at IETF Last call, I discovered that compared to previous documents, it contains no mention of mandatory to implement ciphersuites. In a discussion with Paul Hoffmann, I was pointed at various other RFCs that specify ciphersuites, and informed that the IESG and WG had approved the current situation. However it seems to me that somebody looking at the IKE documents would be likely to come to this document first and would find it difficult to locate the auxiliary documents without considerable effort (and risk of missing some). I continue to believe that f there is not to be a list of appropriate ciphersuites here, there needs to be some pointers to places to look. A number of my comments have been implemented, but there are quite a few that I have seen no response to amd have not been implemented. The list below represents the remaining comments. I have left in a number of comments regarding the cut off time (publication date of RFC 3406) for updating of registration tables. It strikes me that it would be relatively little work and quite helpful to bring these tables up to date. There are also a number of relatively minor points where items and processes are explicitly not fully specified. Thus could lead to annoying corners where implementations are totally interoperable (e.g., what is the complete set of 'terminators' forbidden in IP_FQDNs? What is an acceptable 'sort of' email address/NAI on EAP?) Finally there are a number of points where it is recommended that network traffic needs to be limited but no concrete guidelines are given. I think that some sort of suggestions for the parameters to be applied (e.g., time constants, number of repeats, backoff algorithm) would be desirable. Major issues: s3.3.4: The draft states that the list of mandatory to implement suites has been removed due to evolution going too fast. However there are effectively some mandatory to implement suites; they are listed in other documents. There should be a way of finding them so that users and implmenters can find them easily. Minor issues: s1: At para 6 in s1 the draft states: The first request/response of an IKE session (IKE_SA_INIT) negotiates security parameters for the IKE SA, sends nonces, and sends Diffie- Hellman values. As a (not really) naive reader, I asked myself 'Why does this text suddenly mention that we need to send nonces and Diffie-Hellman values?' Looking back at the text so far I realized that the text has not introduced the techniques that it is going to use to establish the authenticated IKE channel etc. It is assumed that readers know that as soon as D-H is mentioned we are talking public key cryptography. A paragraph explaining the underlying ideas would be useful. s1.2, last para: Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with any value other than NONE. Implementations SHOULD omit the whole transform substructure instead of sending value NONE. Does 'cannot contain' conflict with the 'SHOULD'? I am unclear what an implementer would do if s/he chose to do otherwise than omit the transform structure in the light of the previous statement. s2.1, last sentence: The retransmission policy for one-way messages is somewhat different from that for regular messages. Because no acknowledgement is ever sent, there is no reason to gratuitously retransmit one-way messages. Given that all these messages are errors, it makes sense to send them only once per offending packet, and only retransmit if further offending packets are received. Still, it also makes sense to limit retransmissions of such error messages. Does this need to be more precise? Some explicit policy for restricting retransmissions? Possibly in s2.21.4. s2.3: Should there be some discussion of the interaction of rekeying of the IKE_SA and windows? Presumably a rekey message should not be actioned until all previous messages have been responded to. Likewise receiving a Message ID with a sequence number bigger than that in the rekey message should be very suspect! Should the INVALID_MESSAGE_ID notification be sent in this case (and before or after the rekey?) There might be some knock on into s2.8 where rekeying is discussed. And maybe into s2.25? s2.4, para 2: The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response
Re: Gen-art review of draft-ietf-ipsecme-ikev2bis-08.txt
Paul Hoffman wrote: At 2:37 PM + 3/19/10, Elwyn Davies wrote: Not ready. The document contains a lot of minor niggles and nits plus a major item that I am not sure the IETF should support: this is the removal of all mention of mandatory to implement security suites from the document. I appreciate the difficulty of keeping up to the minute, but it seems to me that this is outweighed by the difficulty of guaranteeing interoperability. If the security landscape is so unstable, we have a bigger problem perhaps. Whether this change is acceptable to the IAB, the IESG and the wider IETF is not something I can resolve. . . . Major issues: s3.3.4: The draft states that the list of mandatory to implement suites has been removed due to evolution going too fast. Is this acceptable? draft-ietf-ipsecme-ikev2bis is a revision of RFC 4306, and the paragraph in question about removing the mandatory-to-implement suites is copied directly from RFC 4306. When the original WG published RFC 4306 over four years ago, it decided to split out the suites into what became RFCs 4307 and 4308. draft-ietf-ipsecme-ikev2bis changes nothing here. Does that clear up your issue, or are you saying that draft-ietf-ipsecme-ikev2bis should reverse the old policy and explicitly pull in the text from RFC 4307 and RFC 4308 into the new document? --Paul Hoffman, Director --VPN Consortium Neither. The omly mention of mandatory to implement suites is in s3.3.4 where it appears to imply (to praphrase) that mandatory to mplement has been removed because we can't keep up. This can be quite happily be read as 'removed to the bit bucket'. As it stands a naive reader might conclude that he can't guarantee much at all since there are no pointers to where the list has been removed *to*. This is the master specification for IKE if I understand correctly. It had better say that there MUST always be some mandatory to implement algorithms, but it is perfectly legitimate to hand of the listing of those to some other RFC that is less onerous to update. It would be IMO a good idea (as is done with all the rafts of updateable lists) to link to the starting points of the chain of documents that tells an implementer what are currently the required protocols by referencing RFC 4307 and RFC 4308, but again reminding us that there maybe heirs and successors. So easy enough to solve. Regards Elwyn ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-ipsecme-ikev2bis-08.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. Document: draft-ietf-ipsecme-ikev2bis-08.txt Reviewer: Elwyn Davies Review Date: 18 March 2010 IETF LC End Date: 18 March 2010 IESG Telechat date: (if known) - Summary: Not ready. The document contains a lot of minor niggles and nits plus a major item that I am not sure the IETF should support: this is the removal of all mention of mandatory to implement security suites from the document. I appreciate the difficulty of keeping up to the minute, but it seems to me that this is outweighed by the difficulty of guaranteeing interoperability. If the security landscape is so unstable, we have a bigger problem perhaps. Whether this change is acceptable to the IAB, the IESG and the wider IETF is not something I can resolve. One niggle that I felt represented a rather lackadaisical approach, was the retaining of the publication date of RFC 4306 as a frozen point in time for the purpose of documenting the state of the world as regards lists of configurable lists. I would have preferred the losts to be up to date at the publication of *this* RFC. There are also a number of relatively minor points where items and processes are explicitly not fully specified. Thus could lead to annoying corners where implementations are totally interoperable (e.g., what is the complete set of 'terminators' forbidden in IP_FQDNs? What is an acceptable 'sort of' email address/NAI on EAP?) Finally there are a number of points where it is recommended that network traffic needs to be limited but no concrete guidelines are given. I think that some sort of suggestions for the parameters to be applied (e.g., time constants, number of repeats, backoff algorithm) would be desirable. Major issues: s3.3.4: The draft states that the list of mandatory to implement suites has been removed due to evolution going too fast. Is this acceptable? Minor issues: s1: At para 6 in s1 the draft states: The first request/response of an IKE session (IKE_SA_INIT) negotiates security parameters for the IKE SA, sends nonces, and sends Diffie- Hellman values. As a (not really) naive reader, I asked myself 'Why does this text suddenly mention that we need to send nonces and Diffie-Hellman values?' Looking back at the text so far I realized that the text has not introduced the techniques that it is going to use to establish the authenticated IKE channel etc. It is assumed that readers know that as soon as D-H is mentioned we are talking public key cryptography. A paragraph explaining the underlying ideas would be useful. s1.2, last para: Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with any value other than NONE. Implementations SHOULD omit the whole transform substructure instead of sending value NONE. Does 'cannot contain' conflict with the 'SHOULD'? I am unclear what an implementer would do if s/he chose to do otherwise than omit the transform structure in the light of the previous statement. s2.1, last sentence: The retransmission policy for one-way messages is somewhat different from that for regular messages. Because no acknowledgement is ever sent, there is no reason to gratuitously retransmit one-way messages. Given that all these messages are errors, it makes sense to send them only once per offending packet, and only retransmit if further offending packets are received. Still, it also makes sense to limit retransmissions of such error messages. Does this need to be more precise? Some explicit policy for restricting retransmissions? Possibly in s2.21.4. s2.2: Maybe should mention that retransmissions MUST use the same Message ID. s2.3: Should there be some discussion of the interaction of rekeying of the IKE_SA and windows? Presumably a rekey message should not be actioned until all previous messages have been responded to. Likewise receiving a Message ID with a sequence number bigger than that in the rekey message should be very suspect! Should the INVALID_MESSAGE_ID notification be sent in this case (and before or after the rekey?) There might be some knock on into s2.8 where rekeying is discussed. And maybe into s2.25? s2.4, para 2: The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response, not as a separate exchange afterwards; receiving parties MAY ignore it in other messages. What should receiving parties do if they *do* receive it and *don't* ignore it? Since it 'MUST be sent in the first IKE_AUTH' receiving at any other time is a protocol error and should cause some response (like dropping
Gen-art review of draft-ietf-dhc-dhcpv4-vendor-message-01
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. Document: draft-ietf-dhc-dhcpv4-vendor-message-01.txt Reviewer: Elwyn Davies Review Date: 5 February 2010 IETF LC End Date: 17 February 2010 IESG Telechat date: (if known) - Summary: Almost ready. I note that (AFAICS) the existing DHCPv4 standards do not specify the behaviour of clients and servers receiving message types that they do not understand. Several new message types have been defined since RFCs 2131 and 2132 were published. These standards and this document tacitly assume that reception of these new message types by existing clients or servers will not cause damage (relays should just forward them without problem). Major issues: None Minor issues: s3, para 3: This paragraph contains weasel words about 'good networking practices' that 'MUST be used'. This is untestable as it stands. Is this anything more than dealing with non-replies, not flooding the network with repeats and not hanging up if the partner never does answer? Also, as observed above, servers or clients that do not (yet) implement this capability do not have a defined behaviour when receiving this new type of message. There is a tacit assumption that they will be silently dropped without causing any problems. s7 and s4, next to last para: s4 specifies RFC 3396 as 'MUST support' This makes RFC 3396 a normative reference, not informative. Arguably the last para of s4 makes RFC 3925 normative as well. Nits/editorial comments: s4, top of page 5: 'Option codes 0 and 255 have no pre-defined interpretation or format': This comment (duplicated from RFC 3925) is confusing to the uninitiated reader. If I understand correctly, this is intended to contrast with the 'basic' options in DHCPv4 where options 0 and 255 are 'special' - i.e. no length code. I suggest adding at the beginning of the sentence: 'Unlike option codes in DHCPv4 [RFC2131], option codes 0...'. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Carsten Bormann wrote: What we need is the ability to write drafts with a standard issue word processor. Why? I suppose if there were indeed a *standard* word processor, this might be feasible, but I think by standard issue you mean commercially available. http://www.xmlmind.com/xmleditor/ Commercial, and the personal edition is available at no cost. I've gotten non-CS people up to speed on that tool in no time. Best with: http://code.google.com/p/xml2rfc-xxe/ +1 This is my preferred mechanism (thanks to Bill Fenner). It isn't totally perfect but it makes it very difficult to produce invaliud xml and does give you a good idea of what you will get. One colleague has had problems due to exploiting (or maybe just not getting caught by) some of the laxities in earlier versions getting tightened up later, but it is generally easy enough to fix things up. Bill's verifier is very helpful for this purpose. http://www.fenron.com/~fenner/ietf/xml2rfc-valid/ As regards documentation, there are two sets of tutorial slides (maybe could be described as 'basic' and 'intermediate' - I wrote the latter). The FAQ is very useful and there are several templates, including the one I did to accompany the tutorial I did. This has lots of explanatory text in it with many examples - there is a stripped down version for when you are experienced. These all fill in the holes left by the basic documentation IMHO, including the complete list of PIs and what they do. http://xml.resource.org/xml2rfcFAQ.html Regards, Elwyn (But then, I use Emacs, which is non-commercial and free.) Gruesse, Carsten ___ 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: Update to the IETF Web Site
I agree with this point. It would also be good to have 'parent' links on these sub-pages. I note that the same problem occurs if you select the 'Brief' option on the menu. [Q: will the 'customize view' be something one can select on startup (e.g. by a ?string in the URL)? - I am not sure how useful the different versions are if you have to decide to go to brief (for example) by an extra mouse click. If I like that style it would good for me to bookmark the style.] (More points below) Dearlove, Christopher (UK) wrote: I asked a colleague who is not involved in the IETF for a comment, to see how it passed test 1 below. His first reaction was positive. But then we noticed a problem. He's running Firefox with noscript. He gets a simplified version of the left hand bar - no subentries. And there is no indication to him he was missing links, and even when he, say, clicks on About the IETF, the page below doesn't have substitutes for the missing Mission, Standards Process and Note Well links (which I think it should - I haven't checked the other similar cases). He, and I, don't see any reason why this should be script generated - or if the alternative views is seen as so important (I'm not sure why) why the noscript version doesn't show all information. Additional points: NOMCOM: Only appears on the Home 'at a glance list' and not in the menus - A set of 'other bodies' menu links would probably be useful with Nomcom, iaoc, rfc ed, tools team, edu team (etc) Various things irritated me about the left hand menu: - The style is very inconsistent between pages at present.. maybe this will be fixed in due course (e.g. data tracker pages have a different menu style and colour, tools site is different, wikis are different). IESG pages are not all the same. - The change of style for the 'advanced' menu seems rather gratuitous at present (I don't see anything new in the way of access methods etc. ). I am unclear that four choices is really essential. - Using Firefox v3.0.11 the aesthetics of the display of the menu are rather horrid in some cases (I think this is to do with first visits to a page) - The menu first displays with some large blocks with the upper level titles in white on larger deep blue boxes (if I can hold the flash in my mind correctly) before redisplaying in its final form. This is unpleasing. - Is it deliberate that the top level links don't change colour after you have visited them whereas subsidiary and on-page links do? I don't know that colour change is really useful for the menu.. but actually I found the menu more pleasing and helpful with the 'visited' colour scheme (i.e. top level links in dark blue, sublevel links in red/brown). Overall: The main page had a terribly cluttered feel to it. I would prefer more white space and the logo writ large. Provide the 'At a glance' page as a site map on a separate page - after all it mostly (but of course not quite) just duplicates the menu at the moment. The direct links to the RFC Editor site don't fit in very well because of the different style.. yes they are useful but psychologically they should be clearly distiguished by being in an external link category (or have their style brought into line).- the relationship between IETF and RFC Editor makes this all a bit strange. And there is no menu to help you get back.. I believe you could display the RFC Editor site pages with the left menu still in place (Don't know the details but it is faniliar from shopping sites etc) Similarly the direct displays of RFCs etc lose the menu so you can't navigate back other than by browser back button - not perhaps so much of a problem for say the RFC repository (although I would often find it useful). However, some pages take you to a display of an RFC by other routes (e.g the WG chairs page, MIB Review Guideleines displays RFC 4181). One solution for the repository would be a 'display in a separate tab/window' button as well the straight 'Go' (I can't right click to specify new tab/window). There is still a learning exercise to be done when using the site: The menus do not contain all of the links that appear on the various 'at a glance' pages. That means there are (slightly) hidden things Maybe hanging all the 'at a glance' pages together into a directory/site map (maybe with next/previous links) would make it clearer to be able to run through ALL the options when you believe there is something there but *just can't find it* (like when I was trying to track down the nomcom link just now). Regards, Elwyn ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-monami6-multiplecoa-10.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. Document: draft-ietf-monami6-multiplecoa-10.txt Reviewer: Elwyn Davies Review Date: 24 November 2008 IETF LC End Date: 17 November 2008 IESG Telechat date: (if known) - Summary: This document is almost ready for the IESG. It has a number of minor issues plus a fair number of editorial nits. I am sending the editirial issues to the authors separately as there are lots of acronyms needing expansion and minor english improvements that woild be tedious to transcribe. Apologies for the late review. Comments: Minor Issues: Backwards compatibility: It would be helpful to explain in the introduction why this proposal is backwatds compatible with the RFC 3775 scheme. The explanations are there but are buried in the error cases of s5.7 and is easily mossed (as I did on early reading). Extension to IPv4 correspondents etc: Something about this in the ontroduction would also help. s2 and several other places (s4.2, s5.1): Use of zero as a binding ID (BID) is forbidden. It is unclear why this value is not allowed - it does not AFAICS specify reversion to RFC 3775 behaviour or anything similar: Forbidding it seems gratuitous. s2: Specifying that the BID must not be negative is sloghtly confusing because the protocol is specified so that negative values cannot be carried. s4.2 (two places), s6.2 (2nd bullet), s6.2 (6th bullet, 1st sub-bullet): The length of the Binding Address mobility option for the IPv4 case is specified inconsistently. Some places have been corrected from 12 to 8 but several others remain. s4.2: The Reserved fiels is normally specified as 'SHOULD be ignored by the receiver'. Makes it easier to cope with later changes. s4.3 (MCOA NOTCOMPLETE) and elsewhere (s6.2): I am dubious about the non-transactional nature of bulk registrations: some additional discussion of why it should be reasonable that a bulk registration can fail in part would be useful s4.3 (MCOA MALFORNED): Some indoication of the circumstances under which this can occur would be useful. s4.3 (MCOA BULK REGISTRATION PROHIBITED) and s5.3: I think there is a 'crner case' in which a bulk registration is sent to a leagcay RFC 3775 node: the node would not be capable of this response. This corner case is not described in s5.3 s5.3: What error status is sent if the user has an Alernate care-of address option with a bulk registration? s5.5.2, last para: Arguably, if the interface is shut down the node os not (IP) connected to its home link! s5.6.3 (2nd bullet) and s6.1 (para 2): Using 'ex.' is not good: It is not a standard abbreviation. I take it 'except' is meant. s5.6.3 (3rd bullet): 'The mobile node SHOULD include the Link-layer Address (LLA) Option': I do not understand how the home agent would be able to send to the mobile node if the LLA option was omitted. I think this is a 'MUST' or maybe a 'needs to'. s5.6.4 (2nd top level bullet): 'the home agent SHOULD use the link-layer address carried by the Link Layer Address option': Again I am not sure what alternative there is? Replace with either 'MUST' or 'needs to'. s5.7 (2nd bullet): s/SHOULD/needs to/: This is not something sthat is an option in the protocol. Also I think it should state that the mobile node needs to assume that none of the attempted registrations were successful. s5.7 (3rd bullet): Explain what could cause the packet to be malformed. s5.7 (4th bullet): Replace 1st instance of SHOULD with 'needs to'. Explain that the 2nd case can occur during 'bootsatrpa' (pointer to s5.9). s6.2 (para 2): If bulk registrations are not transactional (which I would have preferred) need to make it clear what happens with the vrarious multiple mobility options when some are succcessful and some fail. s6.2 (2nd bullet): 'When the Length value is either 8 or 20, the care-of address MUST be present in the Binding Identifier mobility option. If the valid care-of address is not present, the receiver MUST reject the Binding Identifier mobility option and returns the status value set to [MCOA MALFORMED].' This is poorly phrased. If the length is set to 8 or 20, then there is space in the option for an address of some sort. It sort of implies that the bit pattern can be tested to see if it is a valid address - how is this done? It strikes me tht it would simpler just to day that the address is ignored if present when not required (or, if being paranoid, must be the same as was previously registered (if present) when deleting a registration). s6.2 (1st para after lost of bullets): s/can be omitted/MAY be omitted/ Editorial: I have sent a Word document with many nits marked up to the authors. ___ Ietf mailing list Ietf@ietf.org
Gen-art review of draft-ietf-monami6-multiplecoa-10.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. Document: draft-ietf-monami6-multiplecoa-10.txt Reviewer: Elwyn Davies Review Date: 24 November 2008 IETF LC End Date: 17 November 2008 IESG Telechat date: (if known) - Summary: This document is almost ready for the IESG. It has a number of minor issues plus a fair number of editorial nits. I am sending the editirial issues to the authors separately as there are lots of acronyms needing expansion and minor english improvements that woild be tedious to transcribe. Apologies for the late review. Comments: Minor Issues: Backwards compatibility: It would be helpful to explain in the introduction why this proposal is backwatds compatible with the RFC 3775 scheme. The explanations are there but are buried in the error cases of s5.7 and is easily mossed (as I did on early reading). Extension to IPv4 correspondents etc: Something about this in the ontroduction would also help. s2 and several other places (s4.2, s5.1): Use of zero as a binding ID (BID) is forbidden. It is unclear why this value is not allowed - it does not AFAICS specify reversion to RFC 3775 behaviour or anything similar: Forbidding it seems gratuitous. s2: Specifying that the BID must not be negative is sloghtly confusing because the protocol is specified so that negative values cannot be carried. s4.2 (two places), s6.2 (2nd bullet), s6.2 (6th bullet, 1st sub-bullet): The length of the Binding Address mobility option for the IPv4 case is specified inconsistently. Some places have been corrected from 12 to 8 but several others remain. s4.2: The Reserved fiels is normally specified as 'SHOULD be ignored by the receiver'. Makes it easier to cope with later changes. s4.3 (MCOA NOTCOMPLETE) and elsewhere (s6.2): I am dubious about the non-transactional nature of bulk registrations: some additional discussion of why it should be reasonable that a bulk registration can fail in part would be useful s4.3 (MCOA MALFORNED): Some indoication of the circumstances under which this can occur would be useful. s4.3 (MCOA BULK REGISTRATION PROHIBITED) and s5.3: I think there is a 'crner case' in which a bulk registration is sent to a leagcay RFC 3775 node: the node would not be capable of this response. This corner case is not described in s5.3 s5.3: What error status is sent if the user has an Alernate care-of address option with a bulk registration? s5.5.2, last para: Arguably, if the interface is shut down the node os not (IP) connected to its home link! s5.6.3 (2nd bullet) and s6.1 (para 2): Using 'ex.' is not good: It is not a standard abbreviation. I take it 'except' is meant. s5.6.3 (3rd bullet): 'The mobile node SHOULD include the Link-layer Address (LLA) Option': I do not understand how the home agent would be able to send to the mobile node if the LLA option was omitted. I think this is a 'MUST' or maybe a 'needs to'. s5.6.4 (2nd top level bullet): 'the home agent SHOULD use the link-layer address carried by the Link Layer Address option': Again I am not sure what alternative there is? Replace with either 'MUST' or 'needs to'. s5.7 (2nd bullet): s/SHOULD/needs to/: This is not something sthat is an option in the protocol. Also I think it should state that the mobile node needs to assume that none of the attempted registrations were successful. s5.7 (3rd bullet): Explain what could cause the packet to be malformed. s5.7 (4th bullet): Replace 1st instance of SHOULD with 'needs to'. Explain that the 2nd case can occur during 'bootsatrpa' (pointer to s5.9). s6.2 (para 2): If bulk registrations are not transactional (which I would have preferred) need to make it clear what happens with the vrarious multiple mobility options when some are succcessful and some fail. s6.2 (2nd bullet): 'When the Length value is either 8 or 20, the care-of address MUST be present in the Binding Identifier mobility option. If the valid care-of address is not present, the receiver MUST reject the Binding Identifier mobility option and returns the status value set to [MCOA MALFORMED].' This is poorly phrased. If the length is set to 8 or 20, then there is space in the option for an address of some sort. It sort of implies that the bit pattern can be tested to see if it is a valid address - how is this done? It strikes me tht it would simpler just to day that the address is ignored if present when not required (or, if being paranoid, must be the same as was previously registered (if present) when deleting a registration). s6.2 (1st para after lost of bullets): s/can be omitted/MAY be omitted/ Editorial: I have sent a Word document with many nits marked up to the authors. ___ Ietf mailing list Ietf@ietf.org https
Re: [Gen-art] Gen-art review of draft-ietf-rmt-bb-fec-basic-schemes-revised-05
This all seems fine to me.. I'll take a look at the next version when it appears. No worries on the delay... you should see some of mine ;-) /Elwyn Mark Watson wrote: Elwyn, all, Please accept my apologies for the excessive delay in addressing these comments. My plan for addressing these in the -06 draft is below. Regards, Mark On 7/18/08 8:57 AM, Elwyn Davies [EMAIL PROTECTED] wrote: 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. Document: draft-ietf-rmt-bb-fec-basic-schemes-revised-05.txt Reviewer: Elwyn Davies Review Date: 18 July 2008 IETF LC End Date: 29 July 2008 IESG Telechat date: n/a Summary: Nearly ready for IESG. A few minor issues mainly with failure to specify encodings and a couple of corner cases. A few editorial nits noted below. Comments: s3.2.1: Need to explicitly document the encoding used for SBNs (also applies to s4.2.1 and s5.2.1. s5.2.1 also needs to specify encoding for Source Block Length). - Add a clarifying sentence in the introduction that all integer fields are in network byte order. - In the individual sections, specify that the fields are 'x-bit unsigned integers' with suitable values of x. s3.2.1, bottom of page 6/top of page 7: s/is processed at/to process the block by/ (two places) (or some such .. it doesn't read well at present). New sentence: The transport time of a source block includes the amount of time needed to process the source block at the sender transport layer, the network transit time for packets, and the amount of time needed to process the source block at the receiver transport. s3.2.2.2: need to explicitly state encoding of various values (unsigned integers I assume). (also applies to s4.2.2.2, s4.2.2.3, s5.2.2.2 Ok. I will add a paragraph under each figure. s4.2.2.3: The case where the length is zero is a lttle odd! I think it would be worth explicitly stating that (either) the whole object is just one octet long (or) it is four octets padded with zeroes. The latter case might make processing more consistent since otherwise the zero case is special and the only case where the object is not four octet aligned. Ok - I believe there are no users of this field at present so it is safe to include the padding for four-octet alignment. s5.1: it is not possible to encode the source block length of 65536 in 16 bits unless 0 is overloaded to mean 2^^16. This isn't specified. (I assume 'at most' to be read as 'less than or equal'). The maximum size should be 65535. Editorial: Abstract: Need to expand FEC at least once! s1, 2nd para after bullets: genrally not recommended to mention WG s1, last para: s/listed/are listed/ s3.2.1: Need to asociate Source Block Number and SBN explicitly (well, I assume that is what SBN means!). s3.4.1, next to last para: s/implementor of/implementor/ s3.4.2, lastpara: s/substracting/subtracting/ s4.4.2.2: I take the reference in the last para of the section (just above Fig 4) should be to s3.2.2.2. Actually it should be to the figure. s10, 2nd bullet: s/th/the/ s10, 3rd bullet: s/sis/did/ ___ Gen-art mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/gen-art ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-stjohns-sipso-05.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. Document: draft-stjohns-sipso-05.txt Reviewer: Elwyb Davies Review Date: 12 October 2008 IETF LC End Date: 23 October 2008 IESG Telechat date: (if known)- Summary: There are a number of issues which I believe should be considered before this document is ready for the IESG. One possibly major concern is the relationship with the corresponding IPv4 IPSO option as regards IPv4 over IPv6 and IPv6 over IPv4 tunnels. It may be that MLS systems explicitly forbid such situations, but if not this needs to be addressed. I am aware that there has been extensive discussion on the IETF and SAAG lists of the impact of this option on the semantics of transport connections through its concept of virtual networks selected by Sebsitivity Label value. In my opinion the statements made in this document about the limited scope of usage for the CALIPSO option mean that the question of the effect on the wider Internet architecture is irrelevant. This could be reinforced by choosing '01' for the top two bits of the option type so that systems that don't understand the CALIPSO option are required to (silently) discard the labelled packets. There are certainly issues that arise as a result of the extension of the transport end point identfier to include the sensitivity label but I am assuming that the implementors of MLS systems have sufficient knowledge stemming from the corresponding IPv4 systems to provide a solution that does what is needed in the limited context they need to address. An IESG note on the applicability of this option would probably cover the case. Likewise I will not revisit the discussions resulting from the secdir review on the use of the AH integrity checks. Comments: S5: Is there any need to specify an ordering constraint on where the CALIPSO option should appear in the hop-by-hop header? S5, para 2: ‘normally contains’: I think what this means is that each hop-by-hop header should contain EXACTLY one CALIPSO option. If a datagram happens to contain multiple hop-by-hop headers then it might contain more than one. Be explicit! S5, para 2: What about IPv4 in IPv6 and IPv6 and IPv4 tunnels? Is there some relationship between the IPSO/IPv4 security labels and CALIPSO/IPv6 labels? I think maybe the draft needs some coverage of tunnel gateways as a special case of intermediate systems (or end systems - depending on how they are seen by the MLS community). S5.1.1: It would be desirable to explain why the top three bits should be 000 (it is only done in the IANA section presently.) S5.1.1/s9.1: The choice of option flags is rather at odds with the specification. - The option specifies ‘continue processing’ but if the option should not escape onto to the global Internet (and ‘all systems’ in the private networks would be expected to understand CALIPSO options), it would surely be better to specifiy ‘drop if not understood’. - The fact that translation can occur if there is no AH header is at odds with the ‘unchanged en route’ bit. One solution to this would be to ask for two option type values - one for use with AH and one without. S5.1.7: The CRC-16 value is just a bit pattern rather than an integer. S6.2.2/S6.3: ‘A datagram with a Sensitivity Label above the permitted range MUST be dropped.’ In s6.2.2 this is not classified as a security fault but in s6.3 it is. Is there some significance in this difference? S6.3.3, Item 3: ‘If an unlabelled packet has been dropped because the packet is required to be labelled, then a reason code of Administratively Prohibited is used. In all cases, if an ICMP Error Message is sent, then it MUST be sent with the same Sensitivity Label as the rejected datagram.’ Probably need to call out the special case of the unlabelled packet in the second paragraph here. It would also be useful to remind readers that the ‘same label’ ought to be OK for sending back out the incoming interface even though it is no good for the selected outgoing interface. I had to think about this for a while. S6.3.3, Item 3, last para: The term ‘OFF’ is not clear here. One assumes it means ‘not enabled’ but it would be good to be explicit. S6.4, para 5: Presumably the incoming DOI is also involved in the choice? At present it is purely on the standard IP parameters. S9.2: ‘DOI values beginning with decimal 0:0:0 are reserved for private use amongst consenting parties; values in this range will not be allocated by IANA to any particular user or user community. For reasons of interoperability, these DOI values MUST NOT ever appear on the global public Internet.’ Er.. but these options are NEVER supposed to appear on the global Internet. Calling out this range specially
Gen-art review of draft-ietf-sip-media-security-requirements-07
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. Document: draft-ietf-sip-media-security-requirements-07.txt Reviewer: Elwyn Davies Review Date: 10 October 2008 IETF LC End Date: 13 October 2008 IESG Telechat date: (if known) - Summary: This document is almost ready for the IESG. I have a couple of comments and queries about the reasoning in a few of the requirements. Meta-comment: To a non-SIPper the problems to be solved and the requirements look very challenging! And to think S in SIP might once have meant... Disclaimer: Whilst the requirements appear sensible and internally consistent, I have no idea if the set is complete or really appropriate. The explanations in s4 are very helpful and clear for a naive reader like me. Likewise, I do not have the necessary knowledge to verify the statements in the various appendices relating to existing proposals. Again they look reasonable sensible. Comments: s5.1, Requirement R-RTP-VALID: I think some explanation of why '...the key negotiation packets MUST NOT pass the RTP validity check defined in Appendix A.1 of [RFC3550].' would help. This looks like a magic incantation to me at present! s5.1, Requirement R-NEGOTIATE: 'The media security key management protocol MUST allow a SIP User Agent to negotiate media security parameters for each individual session.' Does this imply that the protocol MAY allow the SIP UA to use the same parameters for several sessiosn if it wants to? Might be wise to be explicit.. but I may not understand the situation. s5.2, Requirement R-FIPS: Whilst I know that the FIPS process is often cited other than in the US, this requirement appears very US centric. Are there other similar requirements from other countries that ought to be considered? s5.2, Requirement R-DOS: Whilst I know that it is probably impossible to guarantee that a given solution will not introduce some arcane DOS opportunity that no one has thought of, it seems to me that 'MUST NOT introduce any foreseeable (or, maybe, significant) new DoS vulnerabilities' would be better than SHOULD NOT, which allows for possible weaseling. Nits: s4.2, last line on p.9: s/ares/are/ sA.5.4, MIKEY-NULL bullet: s/computaional/computational/ idnits reports: draft-ietf-sip-media-security-requirements-07.txt(1166): Line has weird spacing: '...ication along...' Several references are now at later versions and draft-ietf-msec-mikey-applicability has been published as RFC 5197. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-forces-model-14.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. Document: draft-ietf-forces-model-14.txt Reviewer: Elwyn Davies Review Date: 5 Setember 2008 IETF LC End Date: 8 September 2008 IESG Telechat date: (if known) - Summary: Nearly ready for IESG. Generally this is a very well constructed and written document dealing with a very complex problem. There are quite a number of minor points that ought to be addressed (although not vast fpr a 132 page document) plus a (largish) number of editorial nits (of which many are related to highly inconsistent choice of what to use for the singular form of metadata - metadata or metadatum - in many cases both are used in the same sentence!) The other consideration that needs to be addressed is the use of normative language in s4 - this is discussed below. Caveat: I haven't done detailed checks of the XML schema and the long bits of XML. Comments: Minor Issues: = s2.3: States that the protocol can be used to discover the Inter-FE topology: is what is meant here? or the intra-FE tolopology? Maybe be a forward reference to s5.3.4 might clarify this if Inter-FE is right? s3.1.1.3, para 2: 'For example, when certain features of an LFB class are optional, the CE MUST be able to determine whether those optional features are supported by a given LFB instance.' I have a vague feeling that this conflicts with the ‘suck it and see’ approach of coarse capabilities from the previous section. Also putting a MUST into an example is unsatisfactory. It isn’t necessary here as this is just the concepts section. s3.2, para 8 (p16): 'In addition, the CE MUST understand where and what type of header modifications (e.g., tunnel header append or strip) are performed by the FEs. Further, the CE MUST verify that the various LFBs along a datapath within an FE are compatible to link together.' I don't believe these are normative MUSTs. There is nothing the model can do to enforce them. s3.2.1, para 8 (p19): '...based on a FRAMETYPE metadata (N=2), or to fork into color specific paths after metering using the COLOR metadata (red, yellow, green; N=3), etc.' The FRAMETYPE and COLOR hargon may be confusing to a novice reader and are not strictly necessary. s3.2.5: Event target terminology: It may be a bit late to change but the term 'target' seems to convey the wrong idea. The 'target' actually is the source of the event. Maybe 'anchor' might be better (taking our cue from xml2rfc). s4: General: The use of 'MUST' in many places but almost always 'may' is IMO confusing. I think the problem is that the normative language is (AFAICS) used to constrain the semantics of the XML schema - it isn't about protocol behaviour. Now this is a reasonable use for this sort of language but I think that at least some of the 'may's should also be MAY. One way I thought about this could be to think of the section as specifying the bahaviour of a tool that checks the semantics of the XML. Stating this explicitly could then make it much clearer whether the right language is being used. Please consider how to improve this. s4.3: 'The load element MUST contain the label of the library document to be included and may contain a URL to specify where the library can be retrieved.' Does anything need to be said about where it would come from if the location os missing? s4.5: The format of 'float16' needs to be defined. There probably needs to be a reference to the right IEEE document that defines float32 and float64. s4.5: 'The boolean data type is defined here because it is so common, even though it can be built by sub-ranging the uchar data type.' Two issues here: 1) sub-ranging hasn’t been talked about yet; 2) this puts doubt into peoples’ minds about the size of the represenation.. is a boolean 8 bits or 1 bit? Does this matter? ss4.5, s4.5.6, para 1, s4.7.6.4, s8.3, 8.4 (and maybe elsewhere): These sections refer to message names from the ForCES protocol. This is not a good idea since it creates a bidirectional dependency between the docs. generic terminology could be used rather than specific message names. I am not entirely sure how to fix s8, but the current situation is not totally desirable. s4.5, last para: 'The predefined type alias is somewhere between the atomic and compound data types. It behaves like a structure, one component of which has special behavior.' BUT *what is* an alias?? We should be told! s4.5.3: arry Elelemt definition: Because of the talk about key fields and use of structure components, it might be cleaner to place this after structs and unions. s4.5.3, para 2: 'The latter should be handled by capability components of LFB classes, and should never be included in a data type array which is regarded as of unlimited size' In the last part
Gen-art review of draft-ietf-rmt-bb-fec-basic-schemes-revised-05
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. Document: draft-ietf-rmt-bb-fec-basic-schemes-revised-05.txt Reviewer: Elwyn Davies Review Date: 18 July 2008 IETF LC End Date: 29 July 2008 IESG Telechat date: n/a Summary: Nearly ready for IESG. A few minor issues mainly with failure to specify encodings and a couple of corner cases. A few editorial nits noted below. Comments: s3.2.1: Need to explicitly document the encoding used for SBNs (also applies to s4.2.1 and s5.2.1. s5.2.1 also needs to specify encoding for Source Block Length). s3.2.1, bottom of page 6/top of page 7: s/is processed at/to process the block by/ (two places) (or some such .. it doesn't read well at present). s3.2.2.2: need to explicitly state encoding of various values (unsigned integers I assume). (also applies to s4.2.2.2, s4.2.2.3, s5.2.2.2 s4.2.2.3: The case where the length is zero is a lttle odd! I think it would be worth explicitly stating that (either) the whole object is just one octet long (or) it is four octets padded with zeroes. The latter case might make processing more consistent since otherwise the zero case is special and the only case where the object is not four octet aligned. s5.1: it is not possible to encode the source block length of 65536 in 16 bits unless 0 is overloaded to mean 2^^16. This isn't specified. (I assume 'at most' to be read as 'less than or equal'). Editorial: Abstract: Need to expand FEC at least once! s1, 2nd para after bullets: genrally not recommended to mention WG s1, last para: s/listed/are listed/ s3.2.1: Need to asociate Source Block Number and SBN explicitly (well, I assume that is what SBN means!). s3.4.1, next to last para: s/implementor of/implementor/ s3.4.2, lastpara: s/substracting/subtracting/ s4.4.2.2: I take the reference in the last para of the section (just above Fig 4) should be to s3.2.2.2. s10, 2nd bullet: s/th/the/ s10, 3rd bullet: s/sis/did/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-rmt-bb-norm-revised-04.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. Document: draft-ietf-rmt-bb-norm-revised-04.txt Reviewer: Elwyn Davies Review Date: 15 April 2008 IETF LC End Date: 17 April 2008 IESG Telechat date: (if known) Summary: A well-written document covering some pretty complex ideas. Technically ready for the IESG but a little up front explanation for the naive reader would help as noted below. Referring to the RFC 3269 guidelines, the document seems to have covered all the (relevant) bases. There might be a question mark about the suggested congestion control mechanisms since they are pre-standard (at best). There are also a few editorial nits. [Aside: The phrase 'the creation of an early NACK slot for these historical NACKers' raised a chuckle here! Non-British readers may not appreciate this.] Comments: s1. A little more explanation of just what a NACK based protocol does would be helpful, together with a note on 'timer-based NACK-suppression' and the idea of 'repairs' and 'repair transmission'. s2.4: 'NACK implosion problems' - this may require a little explanation. s2.5: 'probabilistic timer-based NACK suppression' is just a piece of jargon at this stage in the document as it stands. See comment on s1. One thought I had was to move s2 after s3, but s3 is so large that this may not be appropriate. s3.2.3.1, para 1: s/affect/effect/, s/provided/providing/ s3.9: Without casting aspersions on the competence of the papers referenced as [TfmccPaper] and [PGMCC], the assertion that the solutions described in two academic papers can meet the requirements for congestion control might seem a little cavalier or premature s3.11: Since this covers one of the prime requirements of RFC 3269, it might sit better as a top level section even though it is short. Editorial: (idnits does not report any issues). Abstract: s/negative- acknowledgment/negative-acknowledgment/ s3.1: s/theFEC/the FEC/ s3.2.1, para 2: 'to initiate the NACK processor': s/processor/processing/? s3.2.1, para 3: 'For probabilistic, timer-base suppression': s/base/based/ s3.2.2, bullet 1.: Define what sort of logarithm is meant by 'ln' - and later define 'exp()' s3.2.2, bullet 2.: The page break between page 15 and 16 is particularly infelicitous! s3.2.2: The relationship between the parameters of the C routine and the variables defined on the body of the text is not absolutely clear. s3.2.2, at top of page 16: 'Alternate values may be used to for buffer utilization, reliable delivery latency and group size scalability tradeoffs': s/to for/for/ probably s3.7, para 1: 'only the sender require RTT knowledge' either s/sender require/sender requires/ or s//senders require/ s3.7.4, last para: s/therange/the range/ s4, end of para 3: s/if this acceptable/if this is acceptable/ ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
gen-art review of draft-ietf-rserpool-policies-08.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. Document: draft-ietf-rserpool-policies-08.txt Reviewer: Elwyn Davies Review Date: 11 April 2008 IETF LC End Date: 14 April 2008 IESG Telechat date: (if known) - Summary: Sorry, guys! This document is not in good shape. I know it is, in a sense, the bottom of the tree and somebody reading it would probably be expected to have read in to the subject through the overview (I scanned it) and the protocol documents (I didn't look at them), but I found the introduction opaque, for example: The selection of the pool user is performed by two different entities. Which ones? Selection of what? Selection of which pool user to get this week's star prize? Enough of irony and sarcasm: I have two big technical questions about this document (and hence the whole strategy of rserpool): 1. Why do policies appear on the wire in this way? Do the individual servers care about the policy of the group? Would it conceivably work if they weren't all conforming to some preconfigured policy? Is this expected to change over time? Would weights change over time? Seems to me that policy is a preconfigured characteristic of the group. Maybe weight is something that a server might communicate during sign on. Load is dynamic and probably needs to be propagated from time to time. These are all conflated in these protocol elements. Is this good design? Who really needs to know about policies dynamically? 2. Why should pool users have to worry about pool policy? They just want a server. They don't want to have to (and IMO shouldn't have to) try to second guess the pool controllers by munging around it what was allegedly already a prioritized list, surely? In order to do this, especially in the adaptive cases, the pool user needs the weight and load (according to the policy used) for each server passed in the list of servers in response to the request on the rserpool server. It isn't at all clear that this is what happens. Part of the overall problem is that the document does not clearly state which communications use these items, why they would need to and how frequently. There are also detailed issues with the document, but I have to say that I cannot see that we currently have an effective technical design. It is possible that these points have been discussed in the wg; if so some explanation of the motivation for the arrangement is absolutely essential. I am happy to revisit this review if the authors can explain the motivation and suggest text that will get the naive(ish) reader over the understanding hump. Comments: s3.2: A weight of 0 denotes that the pool element is not capable of providing any service, a weight of 2*n denotes that the pool element is capable of providing a two times better service than a pool element having weight n. For example, weight may define a compute service's computation capacity. That is, a pool element of weight 100 will complete a work package in half of the time compared to a pool element of weight 50. 'two times better'? Any attempt to quantify the meaning of weight beyond a relative ordering of capability will lead to questions such as 'under what conditions?' Leave it to the servers to make what they will of weights - that is the best that the protocol can do. s3 and s4: The encoding of weight and load is not specified other than implicitly. s4.1.3: How does the pool user know some information is out of date? Editorial: s1: Lots of acronyms need expansion. idnits reporst reference issues: Checking references for intended status: Experimental == Unused Reference: 'Dre2006' is defined on line 615, but no explicit reference was found in the text '[Dre2006] Dreibholz, T., Reliable Server Pooling -- Evaluation, Op...' == Unused Reference: 'LCN2005' is defined on line 623, but no explicit reference was found in the text '[LCN2005] Dreibholz, T. and E. Rathgeb, On the Performance of Reli...' == Outdated reference: A later version (-16) exists of draft-ietf-rserpool-common-param-15 == Outdated reference: A later version (-19) exists of draft-ietf-rserpool-asap-18 == Outdated reference: A later version (-19) exists of draft-ietf-rserpool-enrp-18 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-art review of draft-ietf-netlmm-proxymip6-11.txt
Sri Gundavelli wrote: Hi Elwyn, Sorry for the late reply. Thanks for reviewing the updated draft. We will address the two remaining issues. Please see inline. No problem.. I am stuck in a hotel in Toronto, nit getting to IETF. :-((( Snipped the first issue as that should be fine. Outstanding query: s6.1, bullet 2: This bullet refers to '*the* interface identifier' and suggests that it might be retrieved from a Router Solicitation. My original point was that the IID for IPv6 addresses is not necessarily common between the addresses configured on an interface. My comment was a little glib and the authors glossed over the point in their reply. I think this bullet may require clarification to indicate which of the IIDs would be implied here. Particularly if SEND is in use, the IID used for the link local address (that would typically be found in the solicitation) will a.s. differ from the IID used with the address assigned out of the prefix allocated by Proxy MIP. My original point was to ask the authors to clarify whether ProxyMIP actually cares which IID is used and, accordingly, state either that 'it doesn't matter' or specifically which IID should be transmitted. This is the interface identifier (layer-2) and not the L3 identifier. This is covered in the terminology section, Mobile Node Interface Identifier (MN-Interface-Identifier). The need for the L2 interface identifier (such as MAC address) is to predictably identify the interface of a mobile node. The Access Technology Type in combination with the interface identifier is used as the index field in the BCE. Looks like this is not implied. We can point to the MN-Interface-Identifier term and that should probably make it clear. OK.. I think some clarification is required to make sure that you always get the same IID. As specified I didn't grok that it had to be the same one from wherever the node roams to. I think a few extra words will sort that out and then we are done. Thanks Elwyn Thanks again, for the review. Hopefully this addresses all the issues raised by the Gen-art review. Best Regards Sri ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-smime-multisig-04.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. Document: draft-ietf-smime-multisig-04.txt Reviewer: Elwyn Davies Review Date: 7 March 2008 IETF LC End Date: 7 March 2008 IESG Telechat date: (if known) Summary: Mostly fine except for a piece of unclear specification noted below and a few editorial nits. Caveat: I am not a security expert and this should not be taken as an endorsement of the security competence of the proposal. Comments: s3: The first part of the specification for MultipleSignatures is : The fields in MultipleSignatures have the following meaning: - bodyHashAlg includes the digest algorithmIdentifier for the referenced multiple-signatures attribute. - signAlg includes the signature algorithmIdentifier for the referenced multiple-signatures attribute. I am confused by the use of 'includes' here: Do these specs imply that the values of these fields are comma separated lists of all relevant alg identifiers for the signatures? An example with three signatures might clarify what is going on, but the spec should be clarified in any case, I think (but I may just not be sufficiently knowledgable about this sort of spec). Editorial: idnits reports a clean bill of health. Abstract: Expand CMS acronym. s5: s/in a singled/in a single/ s5.2: s/the rquire application/the required application/ s5.3, para 5: The first sentence If signatures are added for the support of [ESS] features, then the fact that an outer layer signature can be treated as a non- significant failure. does not parse. Probably missing 'is invalid' or some such relating to outer layer signature. Appendix B: 'hashes CMS'??? Does not parse! B.1: s/is needed/are needed/ B.2 1/a/ii: s/Reistance/Resistance/ B.2 1/c/iii: s/success/successful/ B.2 2: Expand DER acronym. B.2: is not normative but uses SHOULD NOT. B.2 (2nd para on p18): s/that the attack/than the attack/ ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-rohc-rfc3095bis-rohcv2-profiles-05
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. Document: draft-ietf-rohc-rfc3095bis-rohcv2-profiles-05 Reviewer: Elwyn Davies Review Date: 7 March 2008 IETF LC End Date: 20 March 2008 IESG Telechat date: (if known) Summary: The document is almost ready for the IESG. There are a couple of minor issues that ought to be resolved as detailed below (especially concerning DSCP in IPv4 and IPv6 headers and the notes about out of sequence list specification change packets) and a few editorial nits. Caveat: I have not rigorously checked the ROHC-FN specifications in section 6.8.2.4 although they seem superficially sensible. Comments: s1: It would be worth a sentence to remind readers without deep knowledge of ROHC that the reason that the document does not 'update RFC 3095, etc' is because the protocol negotiates the available profiles between compression endpoints - so the extra profiles defined here just add to the available set. s6.3.x/s6.8.2.1: It would be easier for the reader (and more robust) to use the profile names rather than the expected hexadecimal values when referring to profiles here and anywhere else apart from the definitions. Also there is some inconsistency as to whether the profile names should be capitalized or not. Please choose one version. s6.6.8, next to last para: I believe the 'optional' should be an 'OPTIONAL'. s6.6.9, last para: -- ditto -- s6.6.13: Given that the protocol is supposed to tolerate some reordering, I think some words about how to handle sequentially early packets containing updates to list specifications wuld be useful. Implementations might have to ensure that they can cope with the pre- and post-update specifications for a short period if I understand correctly. s6.9.1: The diagrams of feedback formats are inconsistent (some have bit numbers, some don't). Also values should be specified in the text as well as as labels in the diagrams, and the encosing of the fields needs to be specified (unsigned ints I guess). Appendices A.1 and A.2: The Type of Service/Traffic Class fields are also known as DSCP (DiffServ Code Points) as of six or seven years ago. With the advent of Early Congetion Notification which uses bits in these octets, the values in these fields may not be as 'rarely changing' as would have been expected previously. It is also possible that some of the DiffServ PHBs might lead to more variable values in these fields although this is probably less likely in regions where ROHC is in use. Should this be taken into account? Editorial: General: use of lsb or LSB. The document is extremely inconsistent. General: Capitalization of (Most) Words in Section Headings needs Attention. s5, para 1: s/concepts relates/concepts relate/ s5.1.3, last para: s/to determine/for determining/ s5.2, para 2: s/to always verify the outcome of/for verifying the outcome of every/ s6.2, para 3: s/increasing/to increase/ s6.6.8, para 2: s/notation ./notation./ s6.8.2.1: Extra blank line needed after first bullet for consistency. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-netlmm-proxymip6-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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-netlmm-proxymip6-11.txt Reviewer: Elwyn Davies Review Date: 29 Feb 2008 IESG Telechat date: 06 March 2008 Summary: Version 11 resolves almost all of the issues and nits that I raised in the last call review of version 10. There is one editorial matter to complete the 'ease of reading' and an outstanding query which I think both I and the authors passed over a little lightly at the previous review. An editorial update added to s3, para 4 (just after fig 1) to emphasize the pivotal role of the MN-Identity would be helpful. Something like: 'The authenticated, stable identifier of the mobile node (MN-Identifier) uniquely identifies the mobile node to the LMA(s) as the node roams through the Proxy Mobile Domain.' Outstanding query: s6.1, bullet 2: This bullet refers to '*the* interface identifier' and suggests that it might be retrieved from a Router Solicitation. My original point was that the IID for IPv6 addresses is not necessarily common between the addresses configured on an interface. My comment was a little glib and the authors glossed over the point in their reply. I think this bullet may require clarification to indicate which of the IIDs would be implied here. Particularly if SEND is in use, the IID used for the link local address (that would typically be found in the solicitation) will a.s. differ from the IID used with the address assigned out of the prefix allocated by Proxy MIP. My original point was to ask the authors to clarify whether ProxyMIP actually cares which IID is used and, accordingly, state either that 'it doesn't matter' or specifically which IID should be transmitted. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-netlmm-proxymip6-10.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. Document: draft-ietf-netlmm-proxymip6-10.txt Reviewer: Elwyn Davies Review Date: 18 Feb 2008 IETF LC End Date: 20 Feb 2008 IESG Telechat date: 21 Feb 2008 Summary: This document is well written and is in fairly good shape for submission to the IESG. There are a number of minor issues which ought to be fixed. I think that for a more general reader there are a number of points that are fully covered in the detail but when reading the introduction and protocol overview questions arise which aren't answered until later in the document, and I was left thinking whether the problem had been addressed until much later. I have noted these items in the comments. I believe it would only take a few sentences to lay these issues to rest and make the document easier to understand for those who are not immersed in netlmm. Comments: s3, paras just after fig 2: The para after fig 2 claims that the LMA sets up the bidir tunnel; then the next para claims that the MAG 'establishes' the (same) tunnel. Be clear which one has responsibility. s3, p12: The local mobility anchor, being the topological anchor point for the mobile node's home network prefix, receives any packets that are sent by any correspondent node to the mobile node. I think it should be made clear (assuming I understand correctly what is going on) that this 'correspondent' node does not require any of the MIPv6 correspondent functionality and will not see any specialized MIPv6 messages. It is difficult to think of an alternative term, but this could be confusing. s5.3.4, item 2: Whether the tunnel is deleted is surely an implementation issue. The LMA and MAG could agree to maintain the tunnel even if there are no MNs active on the MAG to save on setup costs. I think this could be a MAY, leaving it up to implementers to optimize if desired. (This is actually discussed later in s5.6.1.. a forward pointer is needed here) s6.1, bullet 2: Does this make any assumptions about commonality of IID between addresses used by the interface? s6.5: I thought it was said earlier that checking that the MN is entitled to mobility services was a MUST. Does the SHOULD refer to the means of authenticating? s8.2: The (M) flag is not added to the Binding Ack message by RFC 4140 (only to the Binding Update msg). s10: The new registry for the Handoff Indicator values is not specified in the IANA Considerations. Areas where some earlier explanation would make life easier for the general reader: 3: I think it would be useful to explain how the LMA knows that the MN that has moved from p-MAG to n-MAG is the same MN.. and hence gets the same prefix somewhere here (the MN_identity, auth and policy I think). s5.1, last para: (it turns out that s5.2 and s6.3 give most of the answers but I was left worrying) States that the mobile node's address prefix would normally be the key for the binding cache entry. This implies that it will be a unique key and hence every MN requires a different address prefix. I think this is sort of implied earlier, but I think it could be stressed at the outset. This raises a couple of more significant issues in my mind: - A MAG using stateless address config will be advertising one prefix per attached MN: if there are lots of them the RA's will be very large. Is this an issue? (not if everything is a pt2pt link, but - How does the MN know which prefix to use if it isn't a pt2pt link? [s5.2 does not address these issues although it clarifies that the prefix per MN mode is used] s6.3 states that it is assumed that links will be pt2pt and hence only one prefix on link. This should be made clear earlier, probably in the protocol overview. I think some additional notes on the Shared_prefix model case and what happens if the links are *not* pt2pt would be helpful: There is a significant risk of the RAs getting very large if multiple prefixes need to be advertised - and it requires slightly different policy to make sure a MN can pick the right prefix if there is more than one prefix advertised. s6.4: I think that explaining where the DHCPv6 server would be and how it would know what prefix to take the address out of would be useful. (A few words plus a pointer to s6.11 would do.) Editorial: (idnits is happy with the document) s2.2, MN-Identifier: Expand NAI and MAC acronyms. s4.1: Associate PAD with Peer Authorization Database. Fig 5: Provide key to various acronyms. s5.1, bullet 1: 'enabled'/'turned off': This reads as if the flag is sometimes present and sometimes not present. Suggest using 'set'/'reset' or 'true'/'false'. s5.1, bullet 3: Define ALL_ZERO. s5.2: The terms Per-MN-Prefix and Shared
Re: Finding information
The information is available on the RFC Editor's web site at http://www.rfc-editor.org/ The RFC Database in various forms such as http://www.rfc-editor.org/rfc-index2.html tells you the status of each RFC and the RFCs that are associated with it by obsoletes/obsoleted/updated relationships etc. Regards, Elwyn Willie Gillespie wrote: 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 ___ 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
Gen-art review of draft-shimaoka-multidomain-pki-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. Document: draft-shimaoka-multidomain-pki-11.txt Reviewer: Elwyn Davies Review Date: 28 December 2007 IETF LC End Date: 1 January 2008 IESG Telechat date: (if known) - Summary: In general this is a well written and, as far as I can see, comprehensive document. I have one major problem with it: it far exceeds the scope advertised in the Introduction. It is very definitely not just about terminology. It certainly gives definitions for names in a taxonomy of PKI Domains but it also defines the requirements and relationships of the components in the various models. At the very least it should advertise itself as a framework or architecture. Given the degree of detail and the (indirect) specification of bits on the wire, I would classify it as a standard. Whether it is a standard rather than a framework depends to some extent on what else you could or would need to specify a fully working system. Personally, not being an expert, the specification seems pretty complete. Not much would need to be changed IMO to make it good as a standard (just saying what it is and removing what appear to be unnecessary weasel words from the security section). This seems to complement PKIX work and has had input for PKIX in the past. Aside from this there are a few minor issues and some editorial nits noted below. Comments: Abstract/s1.1: The objective of this document is to establish a standard terminology that can be used by different Public Key Infrastructure (PKI) authorities who are considering establishing trust relationships with each other. I think that the document goes way beyond the stated aim of establishing terminology. I have no problem with what it does, but there should be honesty in advertising. At the very least this could be described as a framework document or maybe an architecture, but the degree of detailed requirements for the various different models which in many cases (indirectly) specifies the bits on the wire means that it would be quite possible to see this as a standard for PKI Domains. Not being an expert in this area, I am not sure what else a 'standard' might specify if it was built using this document as a 'framework': my immediate reaction is that there isn't much else to specify.. so is it really a standard? Or are we shying away from trying to make standards in this arena (the idea of creating standard terminology argues against this)? s6: Related to the previous point, stating Because this RFC defines terminology and not protocols or technology for implementing the terminology, technology-specific security considerations are not applicable. seems disingenuous. Actually quite a lot of specific technology is mandated. On the other hand, the actual security discussion seems to cover the situation quite well, and I think the disclaimer is unnecessary. Whether the document is recast as a framework or becomes a standard, I don't think much, if any, extra would be needed in the security section. s2.2, para 2: The second sentence appears to be incomplete: A CA which issued a public-key certificate to another (subordinate) CA. s3.2 and many other places: inadvertent trust - This term grates on my tongue. I am unsure if this is just that using it 'intransitively' in this way is not good English. The alternatives such as inadvertent creation of trust relationships are a little clumsy given the number of times it is used - maybe use an acronym? s3.2.3, last para: s/MUST inform all PKI Domains of its membership in all other PKI Domains./MUST inform all those PKI Domains of its membership in any other PKI Domains./ (really informing *all* PKI domains might prove a little onerous!) s3.3.2.1, Considerations: I believe that the first SHOULD is inappropriate. s/SHOULD consider/needs to take into account/ s3.3.2.2, Considerations: /For using the name constraints, the Bridge CA SHOULD pay attention to preventing a conflict of each name space/When applying the name constraints, the Bridge CA needs to avoid creating conflicts between the name spaces.../ I don't think this is a SHOULD: The system is likely to fail if name conflicts are created. Editorial: s2.3.2.1, 3rd sentence: The root CAs MUST distribute trust anchor.. s/CAs/CA/, s/trust/a trust/ s2.3.2.3, Trust Anchor part: s/inappropriate/an inappropriate/ s2.4, para 1: s/Trust List/a Trust List/ (2 places), s/Trust Anchor/Trust Anchors/ s2.4, para 2: s/Detail information of each model is described/The two models are described in detail/; Also there is a duplicate cross reference to s4.1 at the end of the sentence. s3, PKI Domain: NOTE: This definition specifies how domain consists, besides CA domain
Re: Opportunity Re: IPv4 Outage Planned for IETF 71 Plenary
I also think that we must think positive about this. We do need to try things out. I think we started our very first experiments with Wireless LAN at IETF 46 in Washington (I am just trying to find a museum to take the plug-in card Nortel sold(?) me that was never any use afterwards (the old 1Mbps not 802,11b 'standard') ). It has taken us more or less 23 meetings to get to the point where essentially Wi-Fi 'just worked' measured by traffic on the attendees mailing list - it was sometimes a sore trial when 17 ad hoc networks stopped you connecting to the outside world, but we have learnt how to do it - and the vendors and operators have (I suspect) learnt a good deal in parallel. Also one or two ISPs have actually embraced IPv6. Mine (a smallish outfit in the UK) has done so. To my shame I haven't exploited their capabilities yet - my New Year's resolution is to fix this situation. I could run native IPv6 if I find an ADSL modem/router that handles it but in the meantime I can run a tunnel into my firewall box and go native IPv6 elsewhere. Ot will be an interesting experiment and I should be ready to handle any experiments at IETF. Have a look at http://www.aaisp.net/aa/aaisp/ipv6.html Regards Elwyn Jari Arkko wrote: I agree with Leslie on this. It is important to approach this in the right light. Not an interop event; that would be for the implementors of the products. Not a demonstration that IPv4 is still required for most things; we know that already. Not a one hour session where thousand people try to install something new at the same time without a network; there needs to be better model for that. But I think we should still do something. I viewed Russ' call as an opportunity for the IETF community to take a challenge and see what we can make happen by IETF-71. As a personal note, I've had IPv6 turned on my equipment, home site, and company site for years but during the last few months I have tried create a situation where most of own communications would be on IPv6. We converted the company mail servers and gateways that I use to dual stack; some of my own web systems got records too; I ensured that the tools that I use have the right capabilities and defaults to use IPv6; I've contacted the admins of the remaining IETF web sites that still are IPv4 only to ask if they can be converted to dual stack. A significant part of my communications go over IPv6 today, and I have a hope to get this to cover most of my work-related communications. And yes, there's pain. I'm typically the first one to experience the firewall config bug or routing issue on the IPv6 side. But I'm willing... So, I would suggest that we focus on the positive opportunities that Leslie mentioned. Get more things to work. Challenge sponsors to do so as well. Solve some of the remaining problems. Educate ourselves both by doing and by seeing what others do or where they fail. See what works in IETF-71 (but the format of that is less important). Obviously, this needs planning -- Russ' mail is not the plan but rather a call for us to figure out what would make sense. Much work needed... I'm also somewhat surprised by the reluctance of people to try things out. Where's our sense of adventure and eagerness to do new things? We are engineers after all, tinkering with network setups should be fun, no? Boldly go where no group of thousand has ever been... Or at the very least, lets change something for the better. Jari ___ 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
Gen-art review of draft-ietf-ipv6-deprecate-rh0-01
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. Document: draft-ietf-ipv6-deprecate-rh0-01.txt Reviewer: Elwyn Davies Review Date: 21/9/07 IETF LC End Date: 20/9/07 IESG Telechat date: (if known) - Summary: This document is almost ready for the IESG. I have a couple of essentially editorial comments below. Comments: s3: IPv6 nodes **MUST NOT process** RH0 in packets whose destination address in the IPv6 header is an address assigned to them. Such packets...: The rest of the section then goes on to describe just how the node processes the header! I think it should say something like: An IPv6 node that receives a packet with a destination address assigned to it and containing an RH0 extension header MUST NOT execute the algorithm specified in the latter part of Section 4.4 of [RFC2460] for RH0. Instead such packets... s4.2, para 1: The abbreviation RH is not defined (only RH0) so s/type-2 RH/type 2 Routing Header/ Discussion: This document accurately reflects the consensus that was reached in the community but there was considerable discussion about the appropriate course of action having discovered the issue. I think that a short appendix noting the alternative ways forward and the reasons for not taking them would have been useful to avoid revisiting the discussion in future. _ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-ccamp-inter-domain-pd-path-comp-05.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.
Document: draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt
Reviewer: Elwyn Davies
Review Date: 16 Aug 2007
IETF LC End Date: 16 Aug 2007
IESG Telechat date: (if known) 23 Aug 2007
Summary:
I think this document needs significant work on the core description of the
algorithm. I found s4 to be difficult to read and it appears to contain a
number of ambiguities and inconsistencies that should be fixed before it goes
to the IESG. The various sub-cases and routes through the algorithm are not
very clearly expressed IMO. That being said, I think this is essentially a
descriptive problem rather than any issue of principle. There are also a number
of editorial issues (mostly need for acronym expansion) that need fixing in due
course.
Comments:
s3.1: To avoid the sense of surprise when a Path message appears in the last
bullet, I would suggest s/The path (ERO)/The path (specified by an ERO in an
RSVP-TE Path message)/
s4, para 2/3: Presumably para 3 is talking about the 'next hop' being loose or
abstract as is implied by items 1) and 2). It would be good to make this
clear. It would also be worth inserting a sentence making it clear that if the
next hop is strict there isn't anything to do, since otherwise one has to scan
the entire section to verify that this is the case. It is just possible that I
have misunderstood what is going on and some of the stuff *does* apply to
strict hops - in which case the section needs a whole lot more clarity. There
also needs to be some words about the 'simple abstract node' case.
s4: Sending of PathErr. This section states that PathErr messages 'SHOULD be
sent' in several places. Whilst this is consistent with RFC 3209, both of
these documents appear to be (or may be) inconsistent with RFC 2205 which does
not appear to provide any alternative to sending a PathErr when there is a
problem processing a Path message. If it is deemed correct to allow not
sending the PathErr, reasoning should be given as to why this might be
desirable, and what is the alternative (presumably silently ignoring the
message?) and its consequences.
s4, item 1): I think the first sentence ('If the next hop is not present in
the TED.') is probably redundant and is certainly confusing. Part of the
confusion is that the rest of the item appears to only concern loose next hops
but there is no pointer to what happens with the other case of abstract nodes.
I think the description would be more logical with the paragraph on abstract
nodes, from later in the section, moved to before item 1). In that way the
case splitting (strict/loose/abstract) would be much clearer. BTW doesn't the
simple abstract case have to do some of the non-simple work?
s4, item 1, bullet 2: Which domain has to be PSC? The current one or the one
containing the next hop?
s4, item 1: Worth making even clearer that *both* conditions have to be
satisfied.
s4, item 1: 'If the next-hop is reachable, then it SHOULD find a domain
boundary LSR...': What does 'it' represent here? The path necessarily crosses
the boundary (unless we have some very weird topology here ;-) ) so there is
*something* on the domain boundary. What else could it find on the boundary?
I think this is probably a badly expressed story about some other point.
Reflecting on this, it strikes me that this is the key point where the routing
information is pulled into the TE and this is very poorly expressed IMO.
s4, item 1: 'the ABR in the case of inter-area TE or the ASBR in the next-hop
AS in the case of inter-AS TE should be the signaled loose next-hop in the
ERO': Does this mean in the expanded ERO or the original one? If it is the
original one, how is the implementor supposed to check it is an ABR/ASBR?
s4, item 2): The term 'ERO expansion' is not defined in any of the standards -
it is referred to as an alternative shorthand in RFC 4736 (requirements doc).
It needs to be defined.
s4, item 2), bullet 1: This section contains 3 instances of 'SHOULD'. I am
happy with the first one (policy applies). The third one is covered by the
discussion on PathErr above. The second 'SHOULD' strikes me as a 'should' or
even 'is'. What else would be done if it isn't treated this way? Bullet 2,
sub-bullet 1 has a similar construction.
s4, item 2), bullet 2, sub 1: The condition at the beginning of this bullet
could probably be written down more clearly.
s4, item 2), bullet 2/sub 1: 'If the boundary LSR is a candidate LSR for
intra-area H-LSP/S-LSP setup (the LSR has local policy for nesting or
stitching),...': Which LSR has the policy? The boundary LSR or the one asking?
There is an equivalent question for sub bullet 2.
s4, para
Gen-art review of draft-ietf-ipfix-implementation-guidelines-06.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. Document: draft-ietf-ipfix-implementation-guidelines-06 Reviewer: Elwyn Davies Review Date: 20 July 2007 IETF LC End Date: 18 July 2007 IESG Telechat date: (if known)- Summary: Generally in good shape except that the use of RFC 2119 language is generally inappropriate. In many cases the uses of MUST represent reflectionsof requirements in the actual protocol specification, but they are in many cases paraphrases of the normative statements and thus could potentially be confusing or result in conflicts. Given that this is a guidelines document, I believe it would be better to use statements along the lines of 'the protocol (document) requires' to avoid any potential problems. There are a few other minor issues noted below and some editorial matters although the RFC editor will doubtless find some more. Comments: s1.4 suggests that RFC2119 normative language will be used: in an informational document billed as guidelines? In practice it looks as if many of the MUSTs are actually reflections or paraphrases of normative statements in the protocol document, rather than the statements in this document being normative. I think it would avoid the appearance of being normative statements in their own right and/or saying something marginally different from the real normative statement if the wording was altered from 'MUST' to (say) 'the protocol (document) requires'. Others are reflections of necessary facts of life. Instances of MUST: - s3.1, para 3: reflection of IPFIX proto - s3.1, para 4: not a requirement but a fact of life - Exporter has to dothis because it just won't be able to continue if it doesn't. - s3.3, para 1: reflection of statements in s3.4.2 of protocol spec. - s3.4, para 1- first MUST: reflection of statements in s8 of protocol spec. - s3.4, para 1 - second and third MUSTs: I am not clear that these musts are backed up by the protocol spec. The exporting order (s8 of proto spec) appears to be a SHOULD; I guess the collection reception order is implicit but isn't set out explictly in the protocol. - s3.5, para 1: supposed to be a reflection of s10.3.3 of protocol spec BUT protocol spec says max 512 octets as compared with 576 in this doc. Which is right? - s3.5, para 2: relection of s10 of protocol spec. - s4.1, para 3: I guess this is implicit in the statement about malformedmessages in s9 of the protocol spec, but it could be argused that the message is not malformed if it is just using a reserved Set ID. (the associated SHOULD has the same caveat). - s4.2, para 2: fact of life implied by other statements. - s4.2, para 3: see s3.4, para 1, second and third MUSTs. - s4.5.4: reflection of s3.3.1 of protocol spec. - s5.1: Direct quote from protocol spec. - s6.1, para 3: reflection of protocol spec s10.2.4.3 (as is the SHOULD). - s6.1, para 4: Tautology? Certainly a statement of the obvious. - s6.1, para 10: (MUST NOT) reflection of protocol spec. - s6.1, paras 2/3 from end: reflection/direct quote of protocol spec. - s6.2, para 3 and 4 from end: reflection of protocol spec - s6.3, para 3: direct quote - s7.3, para 3: this instance appears to be requiring something that is outside the scope of the protocol to determine. draft-ipfix-info providesseparate information elements to allow reporting of post-modification information but there is nothing (or at least nothing that is guranateed tobe right in all circumstances) that can be done to verify that the data collected is pre- or post-modification. This is intimately tied to difficulty/impossibility of making a truly transparent middlebox. I could noteven see an element that needed to be included to separately specify thenature of the observation point as regards whether it is pre- or post-modification or in the public/private addressing realm of a NAT. Using the'wrong' IEs will not break the protocol or affect interoperability. All that can be done is remind implementers that the appropriate kind of IEs ought to be used to reflect the location of the observation point. - s7.3, para 4: the same considerations as for the previous 'MUST' apply here as well. - s8.1, para 1 (REQUIRED rather than MUST): reflection of protocol spec s11.1 - s8.2, para 3: reflection of protocol spec s11.3 - s9.1, para 3, two places: reflection of s2.1 of ipfix-info draft - s9.2, para 1: reflection of protocol spec s3.2 - s10.2, para 1: reflection of protocol spec s3.3.1 There are several instances of SHOULD and MAY also that need to be assessed in the same way as the MUST instances. In particular the MAY and SHOULD in the last para of s7.3 can only be recommendations. s6.1, para 3: The last sentence appears gratuitous and maybe wrong (I don't know SCTP sufficiently well to know if stream
Re: draft-ietf-v6ops-natpt-to-historic-00.txt
Christian Huitema wrote: From: Noel Chiappa, Monday, July 02, 2007 6:08 AM From: [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) if NAT-PT is to be made historic due to the claims presented in the draft, all of the NAT related documents have to be made historic ... and all of the NAT traversal documents .. has to be banned at once. [EMAIL PROTECTED] 911 The irony of that email address, appended to that message, is pretty good. Noel :-) :-) :-) Firstly, let's be clear that there is a difference between NAT and NAT-PT. The draft makes it clear that a major reason for not wanting NAT-PT deployed is that it effectively ties many of the characteristics of a developing IPv6 network to those of the existing IPv4 network. Whether there would actually be real differences remains to be seen but clamping IPv6 through a transition mechanism seems very short sighted, whatever the technical shortcoming of NAT-PT (or NAT) might be, and the draft tries to stop NAT-PT getting any further deployment because of this. For better or for worse IPv4 NATs are here already and a.s. here to stay. Trying to toss the specifications on the book bonfire is pointless and counterproductive. Likewise trying to kill off the NAT traversal industry would require a suitable Hydra-slaying superhero: Volunteers, two paces forward... wait for it! Maybe IPv6 will do the trick but even there we will require considerable vigilance. However I have a good deal of sympathy for Christian's remarks below. The NAT/traversal industry has many of the hallmarks of the 'new IETF'. Maybe someone should pause and consider why the IETF publishes specifications, or informational documents. Over the last 15 years, I have seen a drift of attitude, basically from engineering to a policy making. In the old engineering attitude, working groups were created because several like-minded engineers wanted to develop some function, or protocol. It was important for them to get together, so they could voluntarily agree on the details. If they did not, each would develop their own version, and there will be no interoperability. The result was documented in a set of RFC, so that whoever wanted to develop a compatible product could. IANA registries are used to ensure that when options arise, the options are numbered in an orderly manner. In the policy making attitude, working groups are created to control evolution of a particular function. The working group members are concerned that someone else might be implementing something harmful to the Internet. Their goal is not so much to develop products as to ensure that non-conforming products do not get developed. IANA registries are used to control extensibility of the resulting protocols, to make sure that bad options never get a number. In short, the IETF evolved from an informal gathering where engineers will agree on how to do things, to a reactive body that mostly aims at controlling evolution of the Internet. Is that really what we want? -- Christian Huitema I hope not, but I fear you are correct. IMO Much of this stems from the ossification and 'lowest common denominator' nature of the deployed network, Arguably, the network/protocol suite is senile and truly novel, architecturally valid improvements are close to impossible because the network cannot adapt to them. The IETF is trying to prevent death rather than enhance life. /Elwyn ___ 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
Gen-art review of draft-ietf-sip-e2m-sec-05.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. Apologies for the late arrival of these comments. Document: draft-ietf-sip-e2m-sec-05.txt Reviewer: Elwyn Davies Review Date: 18 May 2005 IETF LC End Date: 14 May 2005 IESG Telechat date: (if known) - Summary: I think this document needs a fair bit of work before it is ready to go to the IESG. The request to publish as PS to facilitate IANA registration rather than experimental (as merited by the content) appears to be spurious. AFAICS RFC 3261 only requires IETF consensus through an RFC of some suitable kind, not necessarily standards track. The document should be published as experimental. Although this proposed protocol is to be experimental, I believe that the specification as it stands is not sufficiently clear to be able to generate a well-defined result, let alone interoperable implementations. At least part of the problem is linguistic: there are parts of the document that are difficult to decode and the document would benefit from a co-author/editor with greater English language skills. I have flagged some (but not all) of these places below. Apart from issues of document clarity, I think there are several issues that need to be clarified: - Handling integrity and/or confidentiality: The introduction is less than clear that the protocol offers options for integrity alone and combined with confidentiality. I would like to see a much clearer statement of what can be achieved and the variants that can apply to different proxies etc. up front in the introduction and then carried through the document. - Clearer statements on what is protected by integrity (always the whole message?) and confidentiality (potentially different parts depending on proxy destination). Some diagrams (or tables) showing the *complete* sip message with the added e2m security pieces indicating the total message structure and what is protected in each case. - Several pieces (especially around integrity) offer multiple options for ways of doing things. Whilst this is an experimental protocol, and hence some flexibility is desirable, I think there may be too many options - maybe this will get reduced after experiment but it would be good to say this or alternatively to choose one option now. I am also not sure, particularly as regards carrying integrity information in SIP identity, that the recipient is able to determine what has been done by the sender in well-defined way. There appeared to be a certain amount of hand-waving about this and the identity case is not mentioned in the detailed descriptions of behaviour. - The protocol allows for using either pre-shared keys or exchanging certificates. I think there is an issue in the case where a pre-shared key is used and, for whatever reason, the proxy is unable to decipher the results. The specification expects to be able to send back a certificate with a key that the sender can use, but this is either not possible (if pre-shared keys are the only thing the proxy has) or may have some security issues if the proxy is allowed to substitute keys in this way. Basically, the two cases get intertwined which doesn't seem desirable. There are a few more detailed points below. Comments: Abstract: The proposed status is PS although the second para of the abstract admits that the protocol is experimental. This is justified because of the alleged need to have a standards track document for IANA registration. AFAICS from the IANA web site and RFC3261, this is incorrect. Registration requires IETF concensus manifested by means of a published RFC (presumably of a type that submits to IETF Last Call.. like this one). I see no reason why this should not be published as experimental to correctly reflect the status of the content. s1, para 2: s/consists of/may require some or all of/ s1, para 4: 'The proposed mechanisms are based on S/MIME [3], since the major requirement is to have little impact on standardized end-to-end security mechanisms defined in [1], the way of handling S/MIME-secure messages.' The last part of this does not make sense. Maybe s/the way of handling/which already uses/? s2.1, para 1: Expand CMS acronym. s2.1, para 3: The MUSTs in this paragraph are pointless and slightly confusing. Only the source UA knows which proxies and UAS are targeted, so a recipient cannot do any checks to verify that what is there satisfies the MUST. All that is being is stated is that it is a good thing if the list contains exactly the intended recipients and the relevant keys. s2.1, Figures 1 and 2 titles: s/for Sharing/to be Shared/ s2.2, para 1: 'Generating the signature requires the generator, i.e., the UA, has its own public
Re: In support of symbolic references
Brian E Carpenter wrote: On 2007-04-06 08:12, Jari Arkko wrote: Simon, Maybe we can lobby for it to become the default. +1 (I think it would be the right default, even if I agree with John Klensin's concern.) Putting symrefs into all the xml2rfc templates would not be a bad idea. The 'default; in the templates on the RFC Editor's webpage (http://www.rfc-editor.org/formatting.html) are already set to give symbolic references, If you want to suggest a change in the default, writing to [EMAIL PROTECTED] is a good first move. There is an issue with 'no surprises' as Marshall has written on that list. /Elwyn Brian ___ 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: Prague
Tim Chown wrote: On Wed, Mar 07, 2007 at 12:23:21PM -0500, Ralph Droms wrote: I visited Prague about two years ago and had the same experience as Ed. I traveled via the Metro and on foot, visited all the tourist traps; had no problems and never felt unsafe. I second that. The metro system was excellent; it would be interesting to know what the closest stop to the hotel is on the metro map: http://www.dpp.cz/download/schema-metra-v-praze.pdf Tim +1 The nearest metro is Florenc. The nearest exit (Sokolovská) is about 250m from the Hilton Hotel. http://www.csl.cz/en/site/klient/sluzby_kontakty/doprava_na_letiste/do_mhd.htm has suggestions for airport to city centre via bus and metro Bus to ZLIČÍN followed by metro to Florenc looks convenient. /Elwyn /Elwyn ___ 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: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC
Just to clarify the current situation... The statement below says that the recommendation is for RFC 2766 to be reclassified to experimental.. As is implied by the title of the draft, it actually recommends reclassification to Historic. This error results form a piece of history ;-) - The draft is fundamentally the same as draft-v6ops-natpt-to-exprmntl-03. The change in recommendation has been necessitated because it appears that RFC 2026 does not allow the transition to experimental. In the meantime it has become ever more clear that NAT-PT is of dubious value and could limit the development of IPv6 over time. Regards, Elwyn Brian E Carpenter wrote: I think it's important to publish this document, to make it clear why NAT-PT is a solution of very dubious value. Brian On 2007-02-27 20:14, The IESG wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Reasons to Move NAT-PT to Historic Status ' draft-ietf-v6ops-natpt-to-historic-00.txt as an Informational RFC This document recommends that the IESG reclassifies RFC 2766 from Standards Track to Experimental status. ___ 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: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC
Hallam-Baker, Phillip wrote: The core assumption here seems to be that NAT is a bad thing so lets get rid of NAT rather than trying to make NAT work. NAT-PT is not NAT. It does a whole lot more, but it *cannot* do what it claims to do completely, because the semantics on the two sides are different, unlike NAT. Dual stack is a better way forwards for the general case. If you read carefully the draft suggests that there may be scenarios in which a modified form of NAT-PT might be useful, so it is hardly extreme NAT bashing. 3) Exactly why should an application be invited to care about this issue? Because whether the packets pass through a NAT-PT or otherwise affects what the application might expect from the network. NAT does, for better or for worse, solve some real problems. NAT-PT makes new problems: Not good news for a transition mechanism and it militates against future improvements to IPv6. /Elwyn ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-crisp-iris-dchk-06.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. Document: draft-ietf-crisp-iris-dchk-06.txt Reviewer: Elwyn Davies Review Date: 10 February 2007 IETF LC End Date: 21 February 2007 IESG Telechat date: (if known) - Summary: The document itself maybe nearly ready for IESG apart from a few editorial nits (see below). However there are a couple of issues with associated documents that might upset this situation. 1. The DCHK schema is allegedly a proper subset of DREG2 which is 'defined' in an expired draft (and this revision of RFC 3982 isn't mentioned in the crisp charter). So the wg needs to decide if DCHK is intended to work only with DREG2 or whether it can also work with DREG - and if so whether any backwards compatibility is needed. If the former the wg and authors need to ensure that DREG2 progresses (and that DCHK remains a subset of DREG2) or change DCHK to reference the existing DREG and ensure that it is a subset of DREG. 2. The crisp LWZ protocol which is referenced is the subject of a major DISCUSS in the IESG and has not progressed recently. The authors and wg also need to decide if the reference to LWZ is essential to the progress of this document - it could possibly be substituted by appropriate weasel words about using a 'lighter weight' protocol if one is defined. Caveat: I haven't checked the XML schema in detail or checked that it *really* is a subset of the DREG2 schema. Comments: Editorial = Abstract:Expand IRIS acronym. s1: Expand DREG2 acronym. s1. para 2:s/status of domain/status of domain names/ s1, last para: s/effecient/efficient/ s3: Probably good to use the expanded from of DCHK in the section title. s3.1.1: Caption of domain example display: it looks as if XML escapes didn't get substituted. I suspect that this may be to do with using XMLmind to edit the doc. XMLmind recognizes XML metacharacters and substitutes entities in attributes and text outside CDATA segments. So if you input lt; in (e.g) an attribute, the saved text will be amp;lt;. s3.1.1, several bullets: 'period at' doesn't make sense. I think you mean 'duration of grace period at' in each case. s3.1.1.1, description bullet: I think the 'must' should be a 'MUST'. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-art last call review of draft-ietf-webdav-rfc2518bis-17.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. Document: draft-ietf-webdav-rfc2518bis-17.txt Reviewer: Elwyn Davies Review Date: 30/01/2007 IETF LC End Date: 21/01/2007 IESG Telechat date: (if known) - Summary: Apologies for the late review - I missed the aassignment somehow. This document is almost ready for the IESG. There are a couple of issues which need a little clarification IMO and the IANA considerations are suffering from 'a standard problem' - RFC 2518 defined most of things claimed to be needing registration as a result of this document so they are not actually new, but RFC 2518 didn't actually have explicit IANA considerations. Consequently the IANA considerations need to be rephrased to clarify that these are updated definitions rather than new. There are also some minor editorial nits that could get fixed during the update. Caveat: I have not made a detailed check of the syntax/semantics of the examples. Comments: Issues: s4.3, para 2: 'Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and MUST ignore elements they do not understand.' This specification cannot enforce compliance retrospectively! s/MUST/were required to/. s6.6, para 3: 'notifications should be sent': Is this supposed to be a function of webdav? This is the only mention of lock notifications in the document. Potential security implications of lockdiscovery: s6.8 requires a compliant server to support lockdiscovery and expects the response to this request to include the names of principals and potentially the lock tokens for locks being held on a resource. The privacy implications of this are discussed in the Security Considerations but it does not appear to be allowed to restrict or deny this request purely on security grounds. It is likely that some organizations might consider the ability to determine who holds locks is a sensitive matter beyond just issues of privacy, and the responses to lockdiscovery might be mediated by access controls. s9.1: PROPFIND method: It is probably not a big deal, but the ability of 'new' servers to deny depth-infinity PROPFIND requests interacts with the suggestion that they should treat client requests without a Depth header as depth-infinity requests. This may result in a different response from a fully compliant new server as compared with a legacy RFC 2518 server. Is this likely to cause severe disruption to legacy clients? Treatment of 'allprop': I believe that the various statements about which live properties will be returned by 'allprop' are not fully consistent. In the third bullet of s9.1 it is stated that allprop gets you 'property values for those properties defined in this specification' and offers the 'include' element as a way to increase the set of values returned. This interpretation is repeated in the examples (especially s9.1.6) and s14.2. However, the paragraph next but one after the bullets (split across the page 40/41 page boundary) states 'For a live property defined elsewhere, that definition can specify whether that live property would be returned in 'allprop' requests or not.' Finally Appendix F.1 states that the allprop semantics 'have been relaxed so that servers *may* [My emphasis] leave out live properties defined in other specifications'. So it appears that there are three different possibilities here - some clean up is needed. s21 IANA Considerations: The various items here do not require new registrations as they were all registered as a result of RFC 2518 (and RFC 4229). This document updates the registrations (and in a sense formalizes them since RFC 2518 did not have an IANA Considerations section explicitly). s21.1 should refer to RFC 4395 which controls the URI Scheme registry. s21.3 should refer to RFC 4229 which formalized the initial state of the message header field registrations. It occurs to me that I did not check if there are any message headers which were in RFC 2518 but are now dropped - if so this should probably be recorded here. Editorial === general: Check the capitalization of headings (e.g., s7.5.2). s1, paras 9/10: s/new/extra/ (2 places) - they certainly aren't new in this specification. s1, para 11: s/request and response/requests and responses/, s/all all/all/, move cross-ref to Section 17 to end of sentence. s4.3, para 3: s/undefined), not multiple values/undefined); it does not have multiple values/ s6.1, item 4: This is the first appearance of the 'depth' concept and it isn't defined previously. I think something could be usefully added to the terminology section to introduce depth, and specially infinite depth. general: various
Prague (Praha) street maps and hotels (was Re: IETF 68 hotel full)
Search for Praha postcode 18600 or the Florenc metro station which is just nearby (slightly south of hotel). Link to maps centred on hotel: http://www.multimap.com/map/browse.cgi?lat=50.0922lon=14.439scale=5000icon=x (links to some hotels relatively nearby) www.mappy.com finds about 30 hotels fairly close to the Hilton (search for the Florenc metro, zoom out a couple of times and search for hotels) www.map24.com is good for restaurants (search for praha 18600) Elwyn On 12/19/06, Brian E Carpenter [EMAIL PROTECTED] wrote: BTW, www.mappy.com is pretty good for maps and itineraries in Europe. Brian John Levine wrote: I'm having trouble finding Pobrezni 1 186 00 Prague 8 Czech Republic with online maps. I believe hotel is toward the west end of the street, near the bridge to the island in the river: http://maps.google.com/maps?f=qhl=ene=UTF8om=1ie=UTF8z=16ll=50.092682,14.443717spn=0.009375,0.016673 On the other hand, the Hilton web site just offered me a room for IETF week at E152 which appears to be the IETF rate, so it's not all that sold out. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'Procedures for protocol extensions and, variations' to BCP
A couple of nits: s3: It might be helpful to make the first three paras into a bulleted list and add an introductory sentence like: 'There are various ways in which an extension to an IETF can be introduced into the IETF:' s3, para 3: If my understanding is correct, a document from the normal Independent Submissions path cannot get directly on to Standards Track because of the additional requirements for community and IESG review. This being the case, I think it would be good to make this clear here. s3, para 6: s/spark hits/idea is formulated/ (phrase is a bit colloquial) /Elwyn ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: L2VPNs must not be IP(v4)-only
Hi. Maybe I wasn't paying attention but I don't recall seeing messages about this on either the ipv6 or v6ops mailing list. I guess you may have asked around but I'm sure somebody in the wg's could have helped if a public request was made (especially the ndproxy authors). Be that as it may, I agree with Pekka that this document should not proceed without the IPv6 case being addressed. As regards what needs to be done, I guess that RFC4389 provides most of the information - note that RFC4389 is classified as experimental and there may be some discussion as to whether the same arguments that lead to this classification apply to the whole of the arp mediation draft. Both any proposed IPv6 support and the existing IPv4 proposals MUST ensure that they have satisfactorily addressed the architectural issues in draft-thaler-intarea-multilink-subnet-issues-00.txt. Regards, Elwyn Shane Amante wrote: Pekka, This topic has come up in the past -- the last time I recall it being a significant issue was IETF 63 in Paris, France. On multiple occasions since then we have asked for volunteers with IPv6 expertise to help complete the IPv6 bits of this I-D. Unfortunately, we have gotten little to no response. Do you wish to help out with this? Or, can you provide a pointer to folks in the IPv6 world that can take a look at this doc and help out? Thanks, -shane Pekka Savola wrote: On Wed, 16 Aug 2006, [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title: ARP Mediation for IP Interworking of Layer 2 VPN Author(s): H. Shah, et al. Filename: draft-ietf-l2vpn-arp-mediation-07.txt Pages: 21 Date: 2006-8-16 ... The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as ARP Mediation. ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. The document says, 10. IPV6 Considerations The support for IPV6 is not addressed in this draft and is for future study. This needs to be addressed throughout the document. The whole point of L2VPNs (IMHO) is that it's agnostic of what protocols users run above L2. Users depend on a transparent L2 service model and this model breaks that assumption. ___ 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: IETF66 - Recommendations for travel from airport to hotels?
Minor clarification in case your ethics are troubling you... Elwyn Davies wrote: Airport shuttles: Unfortunately the Delta doesn't seem to qualify for a free shuttle. The nearest is probably the Queen Elizabeth (900 boulevard Rene-levesque Ouest) which is about 0.25 mile from the Delta.. This doesn't involve taking a second 'free' shuttle as the main, paid-for, shuttle stops here on the way to the central bus station. Alternatives include riding to the central bus station and taking the metro (Orange Line, direction Cote Vertu) three stops from the metro station at Berri-UQAM (under the bus station) to Square Victoria - this station has an exit either in or right in front of the Delta. (Place D'Armes will be better for the hotels closer to the Palais des Congres) Shuttles run approx every 25-35 minutes and are scheduled to take about 40 minutes. BTW for the seriously lazy, the Palais des Congres is on top of the Place D'Armes metro stop which is one stop back towards the central bus station from Square Victoria There are regional commuter trains out to Dorval but the service is seriously sparse at the weekend and just as bad outside of early morning inbound and evening rush hour outbound. Forget it. Fares: Airport shuttle - one way 13 CAD, return 22.75 CAD Metro: per trip any distance (I assume): 2.50 CAD single trip, 11.50 CAD for a six trip card, one day and three day tourist passes available. Tickets sold at stations or on buses (on buses exact change only) Handy links: Airport shuttle bus: http://www.autobus.qc.ca/anglais/aeroportuaire_an.html Useful handily zoomable map of the centre of Montreal (probably the best online city map I have ever seen!): http://www.stcum.qc.ca/English/info/centre-ville2006.pdf The whole city map is much bigger but equally good: http://www.stcum.qc.ca/English/info/reseau2006.pdf Metro map: http://www.stcum.qc.ca/English/metro/a-mapmet.htm - click on any station for local info including a large scale map with station entrance/exit points marked. Bus/metro fares: http://www.stcum.qc.ca/English/info/a-tarif.htm Montreal transport home page: http://www.stcum.qc.ca/English/a-somm.htm Regards, Elwyn ___ 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: IETF66 - Recommendations for travel from airport to hotels?
Airport shuttles: Unfortunately the Delta doesn't seem to qualify for a free shuttle. The nearest is probably the Queen Elizabeth (900 boulevard Rene-levesque Ouest) which is about 0.25 mile from the Delta.. Alternatives include riding to the central bus station and taking the metro (Orange Line, direction Cote Vertu) three stops from the metro station at Berri-UQAM (under the bus station) to Square Victoria - this station has an exit either in or right in front of the Delta. (Place D'Armes will be better for the hotels closer to the Palais des Congres) Shuttles run approx every 25-35 minutes and are scheduled to take about 40 minutes. BTW for the seriously lazy, the Palais des Congres is on top of the Place D'Armes metro stop which is one stop back towards the central bus station from Square Victoria There are regional commuter trains out to Dorval but the service is seriously sparse at the weekend and just as bad outside of early morning inbound and evening rush hour outbound. Forget it. Fares: Airport shuttle - one way 13 CAD, return 22.75 CAD Metro: per trip any distance (I assume): 2.50 CAD single trip, 11.50 CAD for a six trip card, one day and three day tourist passes available. Tickets sold at stations or on buses (on buses exact change only) Handy links: Airport shuttle bus: http://www.autobus.qc.ca/anglais/aeroportuaire_an.html Useful handily zoomable map of the centre of Montreal (probably the best online city map I have ever seen!): http://www.stcum.qc.ca/English/info/centre-ville2006.pdf The whole city map is much bigger but equally good: http://www.stcum.qc.ca/English/info/reseau2006.pdf Metro map: http://www.stcum.qc.ca/English/metro/a-mapmet.htm - click on any station for local info including a large scale map with station entrance/exit points marked. Bus/metro fares: http://www.stcum.qc.ca/English/info/a-tarif.htm Montreal transport home page: http://www.stcum.qc.ca/English/a-somm.htm Regards, Elwyn ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF66 - Recommendations for travel from airport to hotels?
Unfortunately the Delta doesn't seem to qualify for a free shuttle. The nearest is probably the Queen Elizabeth (900 boulevard Rene-levesque Ouest) which is about 0.25 mile from the Delta.. Alternatives include riding to the central bus station and taking the metro (Orange Line, direction Cote Vertu) three stops from the metro station at Berri-UQAM (under the bus station) to Square Victoria - this station has an exit either in or right in front of the Delta. (Place D'Armes will be better for the hotels closer to the Palais des Congres) Shuttles run approx every 25-35 minutes and are scheduled to take about 40 minutes. BTW for the seriously lazy, the Palais des Congres is on top of the Place D'Armes metro stop which is one stop back towards the central bus station from Square Victoria There are regional commuter trains out to Dorval but the service is seriously sparse at the weekend and just as bad outside of early morning inbound and evening rush hour outbound. Forget it. Fares: Airport shuttle - one way 13 CAD, return 22.75 CAD Metro: per trip any distance (I assume): 2.50 CAD single trip, 11.50 CAD for a six trip card, one day and three day tourist passes available. Tickets sold at stations or on buses (on buses exact change only) Handy links: Airport shuttle bus: http://www.autobus.qc.ca/anglais/aeroportuaire_an.html Useful handily zoomable map of the centre of Montreal (probably the best online city map I have ever seen!): http://www.stcum.qc.ca/English/info/centre-ville2006.pdf The whole city map is much bigger but equally good: http://www.stcum.qc.ca/English/info/reseau2006.pdf Metro map: http://www.stcum.qc.ca/English/metro/a-mapmet.htm - click on any station for local info including a large scale map with station entrance/exit points marked. Bus/metro fares: http://www.stcum.qc.ca/English/info/a-tarif.htm Montreal transport home page: http://www.stcum.qc.ca/English/a-somm.htm Regards, Elwyn Yangwoo Ko wrote: Why not just googling? I entered aerobus and montreal at Google, and found the following link. http://www.admtl.com/passenger_services.aspx?id=48 If this is correct, the aerobus takes us to a few points in downtown from which we can take free shuttle to hotels. Nelson, David wrote: Aerobus shuttle bus service runs from the downtown bus terminal (514-842-2281) with several stops before taking the highway. Fares are lower than taxis: $12 to or from Trudeau. And from the bus terminal to the hotel? Presumably taxi or city bus? Any other alternatives? Are they any shuttle busses from the airport that make stops at the downtown hotels? ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
Kevin Loch wrote: Sam Hartman wrote: secIETF == IETF Secretariat [EMAIL PROTECTED] writes: secIETF *Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 secIETF Native firewall (pings, traceroutes etc. are dropped) Please make sure that ICMP messages needed for path MTU discovery are not filtered. Is there a compelling reason to filter ICMP at all? - Kevin This is not a trivial problem. There is a draft in progress which recommends what the v6ops wg believes ought to happen. See http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-recs-00.txt This does include making sure Packet Too Big errors are not dropped so that PMTU works, This is just about to very slightly updated but it is essentially finished. It would be good if we ate our own dogfood in this case (and we can also test whether the draft has the answers right!) Regards, Elwyn ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/iet ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-art review of draft-hartman-mailinglist-experiment-01.txt
Hi. I am going to take my gen-art hat off here because I want to suggest alternatives rather than just assessments. I have no inherent problem with what we are calling meta-experiments, although there are issues regarding whether the community will feel comfortable with just granting the IESG some power to 'do something' without having much idea what it is. Determining what constraints might placed on that power might take as long as actually specifying what should be done. On the other hand if you constrain the powers too tightly you might as well not bother with the meta-experiment. I think that is the problem you have already identified. The main difficulty I have with the draft as it stands is that the last paragraph of s1 says that the experiment will do something definite, but s4 actually just gives the IESG a general power. This is not consistent - it falls between the two stools mentioned above: although s4 suggests what types of delegation are envisaged the IESG can do whatever it likes regarding mailing list control and what actually happens might bear no resemblance to the second half of s4 para 1 and s4 para 2. So I think the draft can go one of two ways: 1 (which I think Sam would prefer): Redraft the memo as purely the meta-experiment and remove the suggestions of what the IETf might do, to avoid any possibility that people might be convinced that this was the only thing that could happen. === Delete the last but one sentence of s1 - the modified document won't actually create any particular level of sanction. Modify the previous sentence: This memo is an RFC 3933[RFC3933] experiment to provide the community with additional mechanisms to manage its mailing lists while the community decides what mailing list guidelines are appropriate. to: This memo is an RFC 3933[RFC3933] experiment which will enable the IESG to provide the community with additional mechanisms to manage its mailing lists while the community decides what mailing list guidelines are appropriate. Remove the 3rd and 4th sentences (from 'Such methods...') of para 1 and the whole of para 2 of s4. Replace the last part of para 4 of s4: While such last calls are encouraged, they are not required. The reason that the last call is not required is that under RFC 2418, no last call is required; there seems to be no reason to have a procedure more strict than that proposed in RFC 2418. Since RFC2418 does not require actions taken to be Last Called, it is explicitly permitted that any procedure put in place under the powers granted by this experiment need not require a Last Call before it is implemented, as there seems to be no reason to have a procedure more strict than is permitted in RFC 2418. If the resulting document is approved as an RFC3933 experiment, then the text removed from paras 1 and 2 can be put to the IESG as a proposal. The main issue with this as an experiment is that there are two sets of evaluations that can be done: - was the meta-experiement a success? - were any procedures adopted under the extra powers succcessful? It is not very obvious how to judge the original meta-experiment especially if the adopted procedures don't work out! = 2. Redraft the document to remove the general power given in s4 - then s1 is accurate, and the experiment would just cover the explicit procedures set up in the second half of para 1 and para 2 of s4. == Thoughts? Regards, Elwyn Sam Hartman wrote: Elwyn == Elwyn Davies [EMAIL PROTECTED] writes: Elwyn I was selected as General Area Review Team reviewer for Elwyn this specification (for background on Gen-ART, please see Elwyn http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Hi. I'm sorry it has taken me so long to get back to your comments. I've been busy trying to clear documents before the Dallas IETF. Elwyn Summary: [Note: This is the first time that I have done a Elwyn Process Experiment review and I will have to stretch the Elwyn usual review criteria a bit. Basically I believe I should Elwyn be looking for internal self-consistency, consistency with Elwyn associated processes and likelihood of damage to the Elwyn functioning of the IETF.] That seems like a good approach. I'm also doing this for the first time so your cooperation in helping me is greatly appreciated. Elwyn I think this draft is NOT currently in a suitable state to Elwyn produce a well-defined experiment. The main reason for Elwyn this conclusion is that the experiment consists of enabling Elwyn a meta-mechanism and suggesting something the IESG might Elwyn possibly do with this power rather than explicitly stating Elwyn that this is what the IESG should put in place. I'd like to focus
Re: Gen-art review of draft-hartman-mailinglist-experiment-01.txt
Hi. Sam Hartman wrote: I am happy to make a change similar to the one you propose in section 1. I'm happy to split the parts of section 4 dealing with what the IESG might do into their own section as an example. That's fine by me.. it should make a self-consistent document. I do not want to remove them completely. Would that be OK As regards gen-art I think it would be fine. Ultimately I am only a small part of the consensus as regards the experiment proposed. Personally, I would prefer that we didn't have to waste inordinate amounts of time on mailing list management. Unfortunately knocking virtual heads together isn't very effective. /Elwyn ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' to Proposed Standard
Bill Strahm wrote: Robert Elz wrote: I cannot see why there's a debate going on here. If someone, anyone, can read a spec, and, in good faith, point out a possible ambiguity in the text, before the doc is finalised, and if fixing it to avoid the problem is easy, what possible justification can there be for not adding a few words to clarify things, and make sure that confusion does not happen? Whenever someone points out a problem like this, the response should be something like OK, if we write it like ... does that make it clear? or perhaps What would you suggest as clearer wording? but never It is clear enough as it is as the latter is already demonstrated to be false. My mother can't read internet drafts either. Should we change our language so that my mother can read and comprehend them. It is assumed that there is a baseline knowledge when we write drafts... If you don't know how MIBs work in general - there are a LOT of problems that you have to sort out before you can provide technical feedback to the community. Someone who is practiced in the art of reading/writting/implementing MIBs isn't going to have a problem with strictly monotonically increasing Indexes - knowing what that means, and how to implement it and test the implementation for correctness. Somone who has been watching a rant on the list recently invovling the work monotonically increasing, MIGHT see the word and get confused. I am not to worried about that - the document really isn't for their eyes anyway (I'm not about to comment on various security drafts either - should they be simplified so I can understand them, I hope I am expected to put in the work so that I understand them instead) There is a fine line between endeavouring to make drafts and RFCs comprehensible to the casual, but technically competent, reader and requiring them to spell out every last convention and piece of 'common knowledge'. The problem, in my experience as a gen-art reviewer, is that most drafts are created and reviewed by what are essentially closed communities (smaller than the total IETF and certainly smaller than the technical community that might expect to read these documents). These communities share a common set of assumptions and 'jargon'. This occasionally (well actually, quite frequently) results in pieces of text which may well be clear to those immersed in the particular art today, but that are less than clear to somebody with a reasonable grounding but not an intimate knowledge of the subject (such as MIBs) (i.e, me in the first instance, and, hopefully, lots of new implementors over the next few years). On the other hand, I would expect the audience to be literate and use a dictionary if a word is unfamiliar (as it might be given that not all our readers have English as a first language or mathematical training). So I am quite happy if a precise word which I can find in the dictionary is used correctly. Or alternatively there is an upfront pointer to a clear definition of the term. Authors should be expecting that their works will be read by people who need to get the background right as well as those actually studying every line, so it is best to use clear and unambiguous language if at all possible: accordingly I agree wholeheartedly with the next comment... Certainly it is possible to explain the wording on the list, and convince the objector that very careful understanding of the context makes the intent clear - but that does nothing for the next person who comes along and makes the same interpretation mistake (perhaps without even realising the possibility for ambiguity, but simply interpreting the text a different way). For the record, although there is some discussion about monotonic vs strictly monotonic, all the cases which I looked at appeared to be used (mathematically and linguistically) correctly and unambiguously, given the surrounding words (since strictly monotonic sequences are also monotonic). In cases where timestamps are involved it has to be monotonic anyway since we don't have clocks with infinitesimal resolution or arbitrarily large numbers of bits to represent timestamps. Regards, Elwyn Bill ___ 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
Gen-art review of draft-hartman-mailinglist-experiment-01.txt
I was selected as General Area Review Team reviewer for this specification (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Document: draft-hartman-mailinglist-experiment-01.txt Intended Status: Experimental (RFC3933 Process Experiment) Shepherding AD: Brian Carpenter Review Trigger: IETF Last Call ending 15 March 2006 Summary: [Note: This is the first time that I have done a Process Experiment review and I will have to stretch the usual review criteria a bit. Basically I believe I should be looking for internal self-consistency, consistency with associated processes and likelihood of damage to the functioning of the IETF.] I will disregard all matters of the appropriateness or otherwise of the timing of this experiment vis-a-vis any discussion of ongoing PR actions. This review will only consider the merits of the proposal itself. I think this draft is NOT currently in a suitable state to produce a well-defined experiment. The main reason for this conclusion is that the experiment consists of enabling a meta-mechanism and suggesting something the IESG might possibly do with this power rather than explicitly stating that this is what the IESG should put in place. My reading of s7.2 of the IESG Charter [RFC3710] is that the IESG has the power to do this sort of thing already anyway. Were the suggested mechanisms eventually adopted, I would have some qualms about the possibility of indefinite bans being possible without allowing a wider (possibly IETF as opposed to IESG) consensus, but that point is currently moot as the actual proposals that would be put in place are not specified by this document. [Aside: Posting policies will need to start covering wikis and issue trackers in the immediate future!] Review: s1: I think that this section of the last paragraph of s1 overstates/mis-states what this document actually does: This memo is an RFC 3933[RFC3933] experiment to provide the community with additional mechanisms to manage its mailing lists while the community decides what mailing list guidelines are appropriate. IN particular this experiment creates a level of sanction between RFC 3934 and RFC 3683 for working group lists and creates sanctions other than RFC 3683 for non-working-group lists. In practice all that s4 mandates is: During the experiment period, the IESG MAY approve other methods of mailing list control besides those outlined in RFC 3683 and RFC 3934 to be used on a specified set of IETF mailing lists. i.e., it enables a meta-mechanism. s4 then goes on to suggest some things the IESG *might* adopt (second half of para 1 and all of para 2 of s4) and the procedures that it must go through to get them adopted. The result of this is (in the first instance) merely the provision to allow the IESG to decide to do something. I don't think this constitutes a well-formed experiment. s3: The section ... and any mailing list hosted on any site or system operated by the IASA or otherwise on behalf of the IETF. still leaves considerable scope for discussion of whether some mailing lists associated with IETF stuff would be covered. In particular I am thinking of pre-BOF lists and auxiliary WG mailing lists which are not hosted on IETF controlled systems but are discussing IETF related stuff. s3: The following sentence 'Mailing lists listed at https://datatracker.ietf.org/public/nwg_list.cgi are explicitly included in this definition.' has been specifically crafted to catch some of the lists where there are currently problems even though these lists are not actually hosted on IETF controlled systems. Although I am not aware of any specific problems, there could be potential legal minefields in the IETF attempting to manage (especially retrospectively) posting rights on mailing lists which are not hosted on IETF hardware. Some existing WG mailing lists are also not hosted on IETF hardware. s4: Para 2 talks about 'managers' of lists. This term has not been defined - in particular non-WG lists only have administrators (aka owners in some cases). s4, next to last para: The piece about last calls appears to confuse last calls relating to the specification of procedures and last calls relating to specific PR-actions (as mandated by RFC3683 but not required by RFC2418). The initial part of the para appears to be talking about the definition of the powers and procedures which the IESG takes and decides to follow but this metamorphoses into consideration of individual 'procedures' taken under the resulting procedures.. too many 'procedures'! In my view the Last Call which has provoked this review really ought to be arriving at consensus on the additional procedures currently 'suggested' in the second half of para 1 and in para 2 of s4 of this document, and the next to last para of s4 should just state that any actions taken under these
Re: 'monotonic increasing'
Hi. Tom.Petch wrote: The phrase 'monotonic increasing' seems to be a Humpty-Dumpty one, used with a different sense within RFC to that which I see defined elsewhere; and this could lead to a reduction in security. Elsewhere - dictionaries, encyclopaedia, text books - I see it defined so that when applied to a sequence of numbers, then each number is not less than its predecessor, so that 1 1 1 1 1 1 1 1 1 1 1 1 2 3 5 8 13 1 2.71828 3.14159 4.18 42 are all monotonic increasing sequences whereas 1 2 3 4 5 6 7 9 8 10 is not. On the definition of monotonic increasing: I just checked my memory with my copy of Apostol (Mathematical Analysis, vintage 1968 or so) and monotonic increasing implies element (n+1) greater than or equal to element n for all n. 'Strictly monotonic increasing' implies greater than. On line http://www-history.mcs.st-and.ac.uk/~john/analysis/Lectures/L8.html confirms this. Within RFC, mostly those related to security or network management, the context of its use implies, in addition, one or more of a) each number in the sequence is different (as in number used once) b) each number is an integer c) each number is one greater than its predecessor (as in message sequencing) . Most likely, an implementation that conforms to the rest of the world definition would interwork with one that conforms to the RFC one, but with some loss of security, since numbers that are intended to be used only once could be reused. Q1) Can anyone point me to an authoritative source that endorses the RFC usage? Q2) Even so, since the rest of the world usage seems to be so widely defined, should we change our terminology, eg specifying seqences to be strictly increasing when that is what is needed? I just did a full text search of all the RFCs using the zvon repository which covers up to RFC3999. the fragment 'monotonic' (including 'monotonically') appears in RFCs 1323, 1379, 1644, 1889, 2326, 2681, 3571 and 3550. All these cases (either about timestamps or TCP sequence numbers) appear to use monotonically increasing in line with the mathematical definition although it is possible that a couple of them (e.g., RFC3571, s4) ought to use strictly monotonic, although the usage is clear from the additional words. In many cases the phraseology is explicitly used because the sequence (of tiimestamps used, for example) does not have every possible integer represented. Do you have a concrete example of your problem? Regards, Elwyn Tom Petch ___ 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: 'monotonic increasing'
Hmm! I don't think I see your problem with any of the usages in the RFCs mentioned. In all cases monotonically is used to express that the sequence is non-decreasing which is in line both with the mathematical definition and the Merriam-Webster online dictionary #2 sense. In some of the cases the sequence required is actually strictly monotonically increasing but the other words make this clear, and since strictly monotonic sequences are also monotonic, it is not wrong. The only one where there could be (IMO) a soupon of doubt is RFC2679 where it isn't absolutely clear whether or not T in the (n+1)-th pair needs to be strictly greater than T in the nth pair, and I suspect it doesn't matter in this case - it certainly wouldn't break interoperability. Regards, Elwyn Tom.Petch wrote: Elwyn To be more concrete, I have some 1800 RFC readily available and find monotonic in 54 of them from RFC677 (1975) to RFC4303. Plucking a few at random, RFC3412 (SNMP) suggests that monotonic increasing would avoid reuse while RFC2406 (IPsec) suggests monotonic increasing can be used in the context of replay attacks. (I accept that in the latter, as in many cases, understanding the context, the whole document or set of RFC, does imply that the sequence should be strictly increasing). RFC2679 (IPPM) is more mathematical in its approach, where I would expect the term to be informed by its use in mathematical textbooks, but it appears not to be Tom Petch - Original Message - From: "Elwyn Davies" [EMAIL PROTECTED] To: "Tom.Petch" [EMAIL PROTECTED] Cc: "ietf" ietf@ietf.org Sent: Friday, February 17, 2006 8:19 PM Subject: Re: 'monotonic increasing' Hi. Tom.Petch wrote: The phrase 'monotonic increasing' seems to be a Humpty-Dumpty one, used with a different sense within RFC to that which I see defined elsewhere; and this could lead to a reduction in security. Elsewhere - dictionaries, encyclopaedia, text books - I see it defined so that when applied to a sequence of numbers, then each number is not less than its predecessor, so that 1 1 1 1 1 1 1 1 1 1 1 1 2 3 5 8 13 1 2.71828 3.14159 4.18 42 are all monotonic increasing sequences whereas 1 2 3 4 5 6 7 9 8 10 is not. On the definition of monotonic increasing: I just checked my memory with my copy of Apostol (Mathematical Analysis, vintage 1968 or so) and monotonic increasing implies element (n+1) greater than or equal to element n for all n. 'Strictly monotonic increasing' implies greater than. On line http://www-history.mcs.st-and.ac.uk/~john/analysis/Lectures/L8.html confirms this. Within RFC, mostly those related to security or network management, the context of its use implies, in addition, one or more of a) each number in the sequence is different (as in number used once) b) each number is an integer c) each number is one greater than its predecessor (as in message sequencing) . Most likely, an implementation that conforms to the rest of the world definition would interwork with one that conforms to the RFC one, but with some loss of security, since numbers that are intended to be used only once could be reused. Q1) Can anyone point me to an authoritative source that endorses the RFC usage? Q2) Even so, since the rest of the world usage seems to be so widely defined, should we change our terminology, eg specifying seqences to be strictly increasing when that is what is needed? I just did a full text search of all the RFCs using the zvon repository which covers up to RFC3999. the fragment 'monotonic' (including 'monotonically') appears in RFCs 1323, 1379, 1644, 1889, 2326, 2681, 3571 and 3550. All these cases (either about timestamps or TCP sequence numbers) appear to use monotonically increasing in line with the mathematical definition although it is possible that a couple of them (e.g., RFC3571, s4) ought to use strictly monotonic, although the usage is clear from the additional words. In many cases the phraseology is explicitly used because the sequence (of tiimestamps used, for example) does not have every possible integer represented. Do you have a concrete example of your problem? Regards, Elwyn Tom Petch ___ 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
Knowing what BOFs are being thought about [was: Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)]
Finding out what BOFs are being plotted is not very easy AFAIK. In the case below there doesn't appear to have been any widespread public announcement of the start of the mailing list and I suspect that is the case for many others. Obviously an announcement of intent to the IETF list or the Announce list is one way for people to tell the world. For those who can't cope with the traffic on the IETF list and to provide a more permanent reminder, it would help to have a 'prospective new work' page on the IETF web site where new pre-BOF mailing lists could be publicised with a time limit so the advert is removed at the end of 1st or 2nd IETF meeting after it was first started (or when a BOF occurs or the WG starts up) to avoid the list getting overly long. Regards, Elwyn Scott Hollenbeck wrote: -Original Message- From: Richard Shockey [mailto:[EMAIL PROTECTED] Sent: Friday, February 10, 2006 10:39 AM To: John Merrells Cc: ietf@ietf.org; Ted Hardie; Hollenbeck, Scott; Lisa Dusseault Subject: Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX) John Merrells wrote: Name of the BOF I dont see a preliminary discussion list on this BOF. That's IMHO is customary. There's a list that's been around since approximately Vancouver. Archives included: https://www1.ietf.org/mailman/listinfo/dix I'll let John answer your other questions. ;-) -Scott- ___ 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
Finding issue trackers for drafts
Hi. One additional piece of information relating to drafts that ism't included in the drafts database is the location of the issue tracker (if any). They aren't all in one place at the moment which makes life more difficult than necessary for the casual inspector... for example... - I was just faced with an email relating to a l2vpn document which I reviewed for the gen-art team which stated that 'there were some issues in the issue tracker' but no note of where I could locate the tracker. Now clearly I can bug the authors but I am sure they have better things to do. - I know where to find some of the nsis issue trackers but I also know they aren't obvious to a casual observer. So two thoughts: - Could this information be collated on the info pages (subject to a good way of finding it out)? - Would it be a good idea to incorporate the location of the issue tracker into drafts as a matter of course (might even encourage their use)? xml2rfc might be able to provide some sort of support perhaps but that isn't essential. Regards, Elwyn ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: how to declare consensus when someone ignores consensus
[EMAIL PROTECTED] wrote: Can you imagine if during every murder trial they had a debate on the humanity of capitol punishment? As a non-US citizen, I am a little hazy about some details of the US legal system. Do I assume that this punishment requires the malefactor to sit through a set period of congressional filibusters? I look forwards to a Supreme Court ruling outlawing it as a cruel and unusual punishment. Regards, Elwyn ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Ietf Digest, Vol 21, Issue 63
, in the sense that it is intended to server as a firewall against misbehaviour by routing domains outside the core. It is true, as Mike StJohns says, that EGP is not a routing protocol; it is also true that this fact has led to serious restrictions in topology and therefore a crash effort is being mounted to replace EGP with a routing protocol, under the direction of the INENG and INARCH task forces. However, maybe we are asking too much of EGP. Perhaps we are trying to make it a technical fix for administrative problems. To avoid bad things like oscillations and routing loops in the face of the diversity (to use a nice word) of the Internet as a whole, EGP or whatever replaces it will always have to use long time constants and provide some sub-optimal routes. At the present time, the Internet is growing largely by accretion of new Autonomous Systems, and this must lead to some degradation as you cross boundaries. If we want better overall performance, we need to persuade these systems to aggregate into bigger systems, each run by centralized and professional Internet management, and each using a carefully-optimized IGP. I go into all this polemic, because lately I have been exposed to an awful lot of technological optimism (ask NASA about that!) about Internetting. I wish we could convince some of the new players in the Internet game that it takes great technical sophistication and wisdom to make this stuff work well. The Anarchy Model of Internetting, while theoretically feasible due to EGP, is not really a very wise way to go. Bob Braden = regards, Elwyn Davies Marshall Eubanks wrote: While we are on the subject, in the archives of the IETF there are proceedings of one Internet Architecture Task Force meeting, in May, 1986. Can anyone fill me in on this entity and what happened to it ? Regards Marshall Eubanks On Jan 16, 2006, at 2:51 PM, Patrice Lyons wrote: Bob, They are talking about the first IETF meeting as taking place on Jan. 16, 1986. What about the IETF meeting as one of the several task forces that Barry Leiner put together while you were still at DARPA? There was also the working group series that preceded the IETF. I recall that Jon Postel had kept the records of this work on the early Internet. Also, do you plan to go to Dallas? The last message to Harold mentions some agreement reached at Tunis with respect to IETF work with the to be formed Internet Governance Forum (at least I think that is what it is going to be called) (see early work on it at http://www.intgovforum.org/. Patrice - Original Message - From: [EMAIL PROTECTED] To: ietf@ietf.org Sent: Monday, January 16, 2006 10:40 AM Subject: Ietf Digest, Vol 21, Issue 63 -- Message: 6 Date: Mon, 16 Jan 2006 11:14:48 +0100 From: Brian E Carpenter [EMAIL PROTECTED] Subject: An important day for the IETF To: IETF discussion list ietf@ietf.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Greetings, The first IETF meeting took place 20 years ago today, on January 16th, 1986, in San Diego, California. There were 21 attendees and Mike Corrigan was in the chair. The IETF has come a long way since then. We'll celebrate this in fine style during the 65th IETF meeting in Dallas, Texas from March 19 to 24, 2006. Brian Carpenter IETF Chair No. 6 -- Message: 7 Date: Mon, 16 Jan 2006 12:30:13 +0100 From: Harald Tveit Alvestrand [EMAIL PROTECTED] Subject: Re: An important day for the IETF To: Brian E Carpenter [EMAIL PROTECTED], IETF discussion list ietf@ietf.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Happy birthday, IETF! And remember to raise an extra toast to Mike St. Johns, who should be coming to his 63rd or so IETF meeting in Dallas. for some of us, this has gotten to be a habit! Wonder how many of the original 21 are still around Harald, attendee since #22 (but missed #29) --On 16. januar 2006 11:14 +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: Greetings, The first IETF meeting took place 20 years ago today, on January 16th, 1986, in San Diego, California. There were 21 attendees and Mike Corrigan was in the chair. The IETF has come a long way since then. We'll celebrate this in fine style during the 65th IETF meeting in Dallas, Texas from March 19 to 24, 2006. Brian Carpenter IETF Chair No. 6 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Message: 9 Date: Mon, 16 Jan 2006 16:00:12 +0100 From: Harald Tveit Alvestrand [EMAIL PROTECTED] Subject: Re: An important day for the IETF To: Noel Chiappa [EMAIL PROTECTED], ietf@ietf.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed --On mandag, januar 16, 2006 09:39:36
Re: A plug for XXE (Re: Alternative formats for IDs)
Seconded. I *have* used it for a production run and whilst it is not perfect it makes document creation and editing significantly easier than typing 'raw' xml even into a syntax-aware text editor. It is also very helpful for proof reading and commenting (spell checker provided). And the standard version is free.. and supported on Windows, Linux and Mac. I used to use the Word template but the freedom from hassle of generating the final documents, the ease of generating references and support of complex numbered lists (almost impossible to achieve in Word) makes xxe/xml2rfc my current tool chain of choice and means I am never going back to Word. Regards, Elwyn (addict) Harald Tveit Alvestrand wrote: --On 13. januar 2006 11:44 -0800 Joe Touch [EMAIL PROTECTED] wrote: This is my impression, from trying to use it as well. I was troubled by 'yet another embedded text system' that necessitated editing source, which seemed like a stone-age throwback when I abandoned such systems in the mid 1980s (Scribe, nroff, etc. at the time). While I appreciate that, in theory: 1. there are WYSIWYG XML editors that *can* be loaded with DTDs 2. Word et al. are moving to XML Bill Fenner has made a plugin available for the XMLMind XML Editor that gives you a lot of assistance in writing XML2RFC documents. I haven't used it for production yet, but it looks wonderful - not WYSIWYG, but WYSIPU - What You See Is Pretty Useful. Details on http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ Harald ___ 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: A plug for XXE (Re: Alternative formats for IDs)
Seconded. I *have* used it for a production run and whilst it is not perfect it makes document creation and editing significantly easier than typing 'raw' xml even into a syntax-aware text editor. It is also very helpful for proof reading and commenting (spell checker provided). And the standard version is free.. and supported on Windows, Linux and Mac. I used to use the Word template but the freedom from hassle of generating the final documents, the ease of generating references makes xxe/xml2rfc and support of complex numbered lists (almost impossible to achieve in Word) means I am never going back. Regards, Elwyn (addict) Harald Tveit Alvestrand wrote: --On 13. januar 2006 11:44 -0800 Joe Touch [EMAIL PROTECTED] wrote: This is my impression, from trying to use it as well. I was troubled by 'yet another embedded text system' that necessitated editing source, which seemed like a stone-age throwback when I abandoned such systems in the mid 1980s (Scribe, nroff, etc. at the time). While I appreciate that, in theory: 1. there are WYSIWYG XML editors that *can* be loaded with DTDs 2. Word et al. are moving to XML Bill Fenner has made a plugin available for the XMLMind XML Editor that gives you a lot of assistance in writing XML2RFC documents. I haven't used it for production yet, but it looks wonderful - not WYSIWYG, but WYSIPU - What You See Is Pretty Useful. Details on http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ Harald ___ 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: A plug for XXE (Re: Alternative formats for IDs)
Joe Touch wrote: Elwyn Davies wrote: I used to use the Word template but the freedom from hassle of generating the final documents I'm not sure what freedom this means; XML still needs to run through a script, just as Word does. you can't do it from inside Word and in my experience the Word process broke about 80% of the time (mostly due to the generic text printer being horribly buggy) but maybe it is better now since I gave up with Word some time ago. [Microsoft were never interested in fixing these bugs - reducing some lines to heights of a fraction of a point and rendering one character per line in an apparently random fashion - and they persisted across multiple releases of Word.] the ease of generating references Commercial software allows BIBTEX references to be imported into citation databases, so this is moot as well. I am sure I could buy some tools but how well integrated with Word would this be and how much would it cost me? makes xxe/xml2rfc and support of complex numbered lists (almost impossible to achieve in Word) I checked your three current I-Ds and five RFCs, and the most complex numbering I saw was G1, G2, ..., P1, P2..., and paragraphs numbered G.1:, G.2: Word has been able to handle all of these since the late 1980's. Was there a more complex example I missed, or one in a pending document that hasn't been issued that you could give as an example? In theory.. my experience was that multiple sets of numbered paragraphs spread across sections was painful and error prone. But ultimately it was just the level of repeated niggles and panics when conversion fails close to the I-D deadline that I don't get with xml2rfc and especially with xxe. Don't let me stop you using Word but I know which set of tools I prefer. Elwyn Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF Trust last call
Apologies for the last minute query - I have only just returned from an extended holiday. Two points came to mind when I read the Trust document: s2.1, Purpose: The phrase 'used in connection with the Internet standards process and its administration' doesn't seem to be very explicit about the IPR created by the process (which is after all what the IETF is supposed to be about). At first reading it sounds to be just about the peripheral stuff related to the process. Not being an IPR lawyer I would not be sure how broadly the phrase would be interpreted legally, but I thought I would ask. Appendix A: I was somewhat surprised that this section doesn't explicitly mention any software used as part of the operations and process. Maybe this is covered by some other part of the IASA agreements? Regards, Elwyn Davies ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-ipsec-ikev2-17.txt
Roland Looking at the RFC Editor queue, it looks as if this is the only document in the complex web of interdependencies between rfc2401bis and ikev2 and their related documents that is still in the EDIT state. All the others appear to be in REF state waiting for it to finish editing. Why this one, which was one of the earlier arrivals in the queue, is now the blockage cannot be deduced from the database. It would certainly clear out a big chunk of queue (and would fill in a big hole in the security standards scene) if it could be finished! Elwyn Eliot Lear wrote: Roland, Looking at the snippet of the RFC queue you provided, the draft blocked on a normative reference to draft-ietf-ipsec-rfc2401bis, which entered the queue in April. It references a bunch of other stuff, but they're all earlier in the queue, and I don't think they're blocked. I think Bill Fenner has a tool somewhere that graphs this stuff. Eliot So currently the ID Tracker says it is in the RFC Editor Queue. 2004-10-04draft-ietf-ipsec-ikev2-17.txt EDIT REFdraft-ietf-ipsec-rfc2401bisIN-QUEUE C. Kaufman, Ed. Internet Key Exchange (IKEv2) Protocol Bytes: 268610 Working Group: IP Security Protocol This is now over a year?! contributing to the heavy tail distribution :-) I really don't want to blame the RFC editor (you have a tremendous workload) or anyone else for this. I just wanted to know whether there are (whatever) problems that hinder progress. Roland ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Venue Selection Criteria
Ole Jacobsen wrote: On Thu, 13 Oct 2005, Hallam-Baker, Phillip wrote: How about adding that the mean outdoor temperature at the time of the year the meeting is being held should be above 0 degrees Centigrade? Why? There is some logic in this.. Participants need to be able to get from airport to hotel to venue on foot/public transport without needing to bring excessive personal protection gear that they might not otherwise own, or experiencing heat stroke because they aren't used to the temperature/humidity (oh, and touristing before/after isn't much fun either). Another related criterion is that the expected weather is not going to produce a high risk of transport disruption.. southern USA in the hurricane season??? continental Canada in December??? Asia in the monsoon season??? whereever in the peak holiday influx season for that region??? More importantly, the venue must be able to maintain a sensible temperature/humidity in the conference rooms (20-23 deg C, 50% Relative Humidity). Remember that the side effect of allowing 80% of people to plug in their laptops is that each of them may be dissipating an extra 150-200 watts of heat into the room over and above what the human body does. This is actually more than doubling the heat load into the room, and cooling systems may not be able to cope - the IETF is an unusual body and it imposes cruel and unusual punishment on cooling systems. Sitting for a week in excessively warm and humid rooms is not pleasant (working efficiency falls off even at 26C). For example, the Paris meeting turned out ok because the outside temperature dropped right about when the actual conference began, but I was at an Interop event in the same building the previous week when the temperatures were much higher, and being in one of the smaller rooms with lots of bodies and more computers was unpleasant.. the cooling just wasn't coping. My mind has blanked out the location, but we had a very unpleasant week in a US venue two or three years ago when the cooling couldn't cope. Reference: http://ergo.human.cornell.edu/studentdownloads/DEA350notes/Thermal/thcomnotes1.html http://ergo.human.cornell.edu/studentdownloads/DEA350notes/Thermal/thcomnotes2.html http://ergo.human.cornell.edu/studentdownloads/DEA350notes/Thermal/thcondnotes.html Other health risks: Would participants need vaccinations before attending? Is it in a malaria risk area? Are there other infectious disease hazards or nuisances - e.g., West Nile fever, Lyme disease, Scottish Highland midges. Even if visas are not required are there any health checks at immigration? The airport (and/or other wide area transport links) need to have adequate capacity and decent connections.. probably not an issue if the venue is sufficiently large but worth checking. The criteria say nothing about accessibility for the differently able. There is also the matter of break time refreshment provision.. succouring 1300 thirsty, half-starved nerds (sorry, IETFers) two or three times a day at a reasonable cost can be a challenge. You need to differentiate the technical requirements of the venue from what the network providers need to do there are some fuzzy edges here e.g., the WAN links Editorial note: You should flag up that continental European conventions are in use for numbers. Regards, Elwyn ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Venue Selection Criteria
Jari Arkko wrote: Elwyn Davies wrote: There is some logic in this.. Participants need to be able to get from airport to hotel to venue on foot/public transport without needing to bring excessive personal protection gear that they might not otherwise own, or experiencing heat stroke because they aren't used to the temperature/humidity (oh, and touristing before/after isn't much fun either). Lets just not specify anything here. Its not like the secretariat would be blindly executing our rules and ending up selecting the Antarctica for the next IETF location. (They wouldn't because the hotel capacity is insufficient.) In other places, you can probably manage short exposure to the elements, particularly if you happen to check beforehand which part of the world you are going to. And yes, this might mean investment to protective gear such as a hat, jacket or a tube of SPF 40. Or a taxi ride. And I've found that touristing is more interesting in extreme conditions. You don't want exact rules..but preferring a 'temperate' temperature range or avoiding likely real extremes is a criterion for choosing one veue over another. More importantly, the venue must be able to maintain a sensible temperature/humidity in the conference rooms (20-23 deg C, 50% Relative Humidity). This is more important. I feel that the rooms are mostly too cold (probably tuned for business suits, not t-shirts). Interesting.. I have not yet found anything cooler than nicely comfortable for me - mostly they are far too hot for my taste but doubtless that might be something to do with BMI! Seriously, the population of laptops (plus the need for inter-seat spacing to accomodate laptop use) may mean that room sizes need to be larger than the nominal capacities that venues quote. It would probably be sensible to quote the space per participant that we expect in meeting rooms and maybe something about chair layouts. Other health risks: Would participants need vaccinations before attending? Is it in a malaria risk area? Are there other infectious disease hazards or nuisances - e.g., West Nile fever, Lyme disease, Scottish Highland midges. Even if visas are not required are there any health checks at immigration? Its really better that people check with their own doctors about this. I at least check before weird trips from our local clinique what the vaccination recommendations are. Absolutely, but choosing a venue where most people (e.g.) ought to be popping malaria prevention pills is something that needs to be thought about.. it means participants need more advance planning and last minute decisions might not be possible (as with visas). The criteria say nothing about accessibility for the differently able. This should be a requirement. Editorial note: You should flag up that continental European conventions are in use for numbers. What numbers? e.g., I take it that 1.300 means we average 13e2 rather than 13e-1 participants. Regards, Elwyn --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: p2p dns (was: Re: UN plans to take over our job!)
Johan: I imagine you have seen this paper on the subject of a p2p DNS substitute based on CHORD, but it is interesting reading for others. http://www.cs.rice.edu/Conferences/IPTPS02/178.pdf Regards, Elwyn Davies Johan Henriksson wrote: On Fri, Sep 30, 2005 at 08:45:29AM +0200, Johan Henriksson [EMAIL PROTECTED] wrote a message of 25 lines which said: a peer 2 peer replacement for DNS tops my internet wish list; Is it a formal call to a new WG? Please provide a candidate charter :-) I'd subscribe immediately :-) is there an interest? I don't have much experience of IETF, much less in taking care of a wg. but if more people would want to work on such a thing, I could look into how to start up such an endeavor. (although I doubt it would grow into a substitute in the end; rather a complement) - Johan Henriksson ___ 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
Comments on draft-iab-link-indications-03.txt
Hi. I did a quick read of this document and have a couple of general comments (plus I spotted a very few trival nits). It seems to be a very useful survey of what has been done in the area of Wireless LAN and the interactions of link indications for hosts connected directly to such links. The architectural concerns and recommendations are then principally derived from this area of study - I agree generally with what is said in these recommendations in the primary situation investigated but I am not sure if the conclusions would be modified if other situations were more explicitly considered. I am not sure without much deeper thinking and indeed a deeper knowledge of the types of links whether the characteristics of the various mobile phone links (which are very briefly mentioned) would have much of an impact on the conclusions. Their behaviour is significantly different from that of WLAN and given the rather limited performance of the browser on my mobile phone I wonder if more advice is needed here! Similarly Bluetooth and other sorts of short range communication; and 802.16 type links don't get much consideration. The draft implicitly concentrates on link indications directly into hosts where they can interact with the transport and application layers as well as the IP and routing control plane. Carriage of link indications beyond the node where they are directly detected is rather frowned upon: I think that some more analysis is needed for situations where the wireless link attaches to a router (a mobile network such as a car or plane comes to mind) and the hosts attached to the wirelesss router don't see the link indications directly. It occurred to me that the nsis work both needs the link indications (to help with rerouting) and could be effectively used to carry the indications - either as a on/off signal or as part of the QoS signaling to tell the application that the bandwidth it was going to get was not what it negotiated originally. Another area whcih is not considered is the usage of link indications for traffic engineering. There is quite a lot to be said about managing layered recovery where multiple link layers can provide both indications of failure and/or rerouting. The total problem in this case is very complex (just which layer should do the rerouting?). I also though that IPv6 was not considered very thoroughly. The following sections should probably say more about IPv6: s1.2: Routable addresses: what about IPv6 addresses? s1.4.2: Needs to consider ICMPv6 ss2.3.1, 2.3.2, 2.3.3: Need to consider IPv6 address configuration Minor point: In s2.4: there should probably be some discussion of the controlability of TCP keepalives - most OS provide very rudimentary capabilities for controlling TCP keepalives and the usual default interval is totally useless for almost any real world application. Editorial nits: s2.1, para 3: (language difficult to parse) s/documents dependent/documents that describe capabilities that are dependent/ s2.2, para 5: s/head/heed/ s4.1, para 3: s/receiving/receive/ s4.3, para 1: s/particular/particularly/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
