Re: SHOULD vs MUST
On 25 jun 2008, at 9:58, Dave Cridland wrote: I think we should be biting the bullet and doing so, however - otherwise we risk having the old behaviour used in new implementations more than it would be otherwise. The primary reason for doing the behaviour you describe is a kind of political correctness, and introduces a political-SHOULD I'm not sure I care for. This shows that it's very important to avoid the situation where there exist implementations of insufficiently mature specifications: once those implementations are out there, the protocols must virtually forever support them. This is of course not compatible with let's ship a 80% workable spec and hammer out what's missing in the next version thinking that is not uncommon in the IETF. -- The trouble with doing something right the first time is that nobody appreciates how difficult it was. - Walt West ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
SHOULD vs MUST case sensitivity
Eric Gray wrote: (By the way, I hope folks are clear that IETF use of these words as normative does not depend upon the case that is used?) This is NOT true. These terms are explicitly defined in all capital letters to make it possible to distinguish when they are being used as normative and when they are not. Sorry, no. Please re-read rfc 2219. Specifically: These words are often capitalized. The key word is often which means not always which means not required. Computer science long ago made the mistake of imposing semantic difference on case differences, which is distinct from other uses of case. Absent explicit specification of case sensitivity for the keywords, the rules of English writing apply, I would think. In text that is not meant to be normative, the special terms should be avoided - even in lower case - but this can lead to exceptionally stilted use of the English language. Not really. Words like can and ought do the job nicely. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
Hi Lakshminath, At 07:11 27-06-2008, Lakshminath Dondeti wrote: Is it really necessary for all the battles to repeat on the IETF list? Why can't the shepherding AD judge the overall consensus? No, it is not necessary. One could read the WG discussion of the topic instead of rehashing the same arguments on the IETF list. The shepherd is there to gather information, get the document through the various stages and provide coordination. The PACT I-D may be a useful read: An IETF effort is designed to resolve engineering choices for one issue and then move to a new issue. It is not reasonable to permit arbitrary criticisms to be raised late in the process, derailing the incremental effort of a WG. It is always reasonable to raise fundamental engineering problems, but it is essential to distinguish these from matters of engineering aesthetics. In particular, the IETF Last Call and IESG review periods are not intended for second-guessing a WG's design choices -- the purpose of an IETF Last Call and IESG review is to focus on the overall viability of the document. I'll also highlight a few points from RFC 3774: Participants are frequently allowed to re-open previously closed issues just to replay parts of the previous discussion without introducing new material. This may be either because the decision has not been clearly documented, or it may be a maneuver to try to get a decision changed because the participant did not concur with the consensus originally. On the other hand, the decision making process must allow discussions to be re-opened if significant new information comes to light or additional experience is gained which appears to justify alternative conclusions for a closed issue. One cause that can lead to legitimate attempts to re-open an apparently closed issue is the occurrence of 'consensus by exhaustion'. The IETF culture of openness also tends to tolerate participants who, whilst understanding the principles of the IETF, disagree with them and actively ignore them. This can be confusing for newer participants, but they need to be made aware that the IETF does not exclude such people. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: SHOULD vs MUST case sensitivity
Dave, See inline below... -- Eric Gray Principal Engineer Ericsson -Original Message- From: Dave Crocker [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2008 12:04 PM To: Eric Gray Cc: IETF Discussion Subject: SHOULD vs MUST case sensitivity Importance: High Eric Gray wrote: (By the way, I hope folks are clear that IETF use of these words as normative does not depend upon the case that is used?) This is NOT true. These terms are explicitly defined in all capital letters to make it possible to distinguish when they are being used as normative and when they are not. Sorry, no. Please re-read rfc 2219. Specifically: These words are often capitalized. The key word is often which means not always which means not required. I assume you meant to refer to RFC 2119, rather than 2219. I specifically refer to usage, rather than RFC 2119. We often do that. You, for instance, recently co-authored an RFC that is a full standard, uses lower case instances of these terms, and does not refer to RFC 2119 at all. RFC 5234/STD 68, I believe. I suspect that this wording is an aspect of RFC 2119 that should be changed - and probably would have been were it not for the fact that capitalization has not always been used consistently and RFC 2119 is supposed to be a Best Current Practices RFC. In English, best current practices cannot typically be used to refer to what we wish to be true. I strongly suspect that RFC 2219 should say SHOULD be instead of are often - if for no other reason than to encourage consistency. Computer science long ago made the mistake of imposing semantic difference on case differences, which is distinct from other uses of case. Absent explicit specification of case sensitivity for the keywords, the rules of English writing apply, I would think. Yeah, you're not that much older than I am. However, in this case, people who actually include a section that lists the RFC 2219 normative terms effectively DO make an implicit specification of case sensitivity and - unless the reader decides to read RFC 2219, the reader may not know otherwise. The statement that should be contained in any RFC that is intended to use the requirements level aspect of RFC 2119 terms is: 'The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.' There is nothing in this statement that indicates that these terms are meant to be anything other than capitalized. In text that is not meant to be normative, the special terms should be avoided - even in lower case - but this can lead to exceptionally stilted use of the English language. Not really. Words like can and ought do the job nicely. Actually, no they do not. As most of us know, can is NOT a synonym for may and (as most anyone who would be familar with the word ought would know) ought is also a synonym for zero. If you decided to use the word may in a non-normative sense - but wished to be consistent with Enlgish usage - you would need to say something like is allowed to. That seems to me to be a fine example of stilted usage. An example of a non-normative use of should is this: The reader should already be aquainted with the contents of ... Assuming this statement is normative is absurd. Re-writing it to use ought makes it read ... reader ought to be ... - which seems like another fine example of stilted English. And a good example of when you might use the word must in a non-normative sense is when describing something that is unavoidable (e.g. - what goes up, must come down) and describing such a thing normatively is also absurd. Would you write what goes up, would need to come down? Strictly speaking, inanimate objects (rocks, balls, etc.) have no needs and many animate objects (kittens, puppies, etc.) would not necessarily feel any such need. And, before you dismiss these as irrelevant examples, ask yourself whether or not the statement a message must have a finite number of octets is normative... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SHOULD vs MUST case sensitivity
Dave Crocker wrote: Eric Gray wrote: (By the way, I hope folks are clear that IETF use of these words as normative does not depend upon the case that is used?) This is NOT true. These terms are explicitly defined in all capital letters to make it possible to distinguish when they are being used as normative and when they are not. Sorry, no. Please re-read rfc 2219. Specifically: These words are often capitalized. The key word is often which means not always which means not required. ... Of course. My understanding that everything in an RFC is normative, unless stated otherwise. If this wouldn't be the case, how could something as important as STD66 be written without a single RFC2119 keyword? BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SHOULD vs MUST case sensitivity
Computer science long ago made the mistake of imposing semantic difference on case differences, which is distinct from other uses of case. Absent explicit specification of case sensitivity for the keywords, the rules of English writing apply, I would think. For better or worse, in IETF we have often intentionally made a distinction between SHOULD and should, MUST and must, and so forth. I don't think we should try to retroactively change the interpretation of existing RFCs that cite RFC 2119. However, it strikes me that such distinctions might be lost when translating RFCs into languages that lack the notion of case, or for which upper cased words would not serve to convey a sense of emphasis or distinction. So it might be the case that a future update to RFC 2119 would include a section about translation of these keywords into other languages. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Update of RFC 2606 based on the recent ICANN changes ?
I have been having a discussion on NANOG about possible problems with the new Top Level Domains coming out of ICANN. It seems like additional TLD domains, beyond just the 4 in RFC 2606, should be either reserved or blocked. Suggestions include .local (apparently used heavily by Microsoft), .internal, as well as maybe translations of .test .example .invalid .localhost into other languages / character sets. I am curious as to whether others feel like this is a potential problem to be addressed (and, not least, whether there is a better mail list for this discussion). Regards Marshall ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Hi, On Jun 27, 2008, at 11:43 AM, Marshall Eubanks wrote: I am curious as to whether others feel like this is a potential problem to be addressed (and, not least, whether there is a better mail list for this discussion). I believe an RFC that provides an IETF-defined list of names (beyond the 4 in 2606) and/or rules defining names the Internet technical community feels would be inappropriate as top-level domains would be quite helpful. Regards, -drc (speaking personally) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SHOULD vs MUST case sensitivity
Eric Gray wrote: (By the way, I hope folks are clear that IETF use of these words as normative does not depend upon the case that is used?) This is NOT true. These terms are explicitly defined in all capital letters to make it possible to distinguish when they are being used as normative and when they are not. Sorry, no. Please re-read rfc 2219. Specifically: These words are often capitalized. The key word is often which means not always which means not required. Computer science long ago made the mistake of imposing semantic difference on case differences, which is distinct from other uses of case. Absent explicit specification of case sensitivity for the keywords, the rules of English writing apply, I would think. In text that is not meant to be normative, the special terms should be avoided - even in lower case - but this can lead to exceptionally stilted use of the English language. Not really. Words like can and ought do the job nicely. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Hi David, At 11:51 27-06-2008, David Conrad wrote: I believe an RFC that provides an IETF-defined list of names (beyond the 4 in 2606) and/or rules defining names the Internet technical community feels would be inappropriate as top-level domains would be quite helpful. Do you mean as in RFC 3675? Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
Brian, Thanks for your response. Please see inline: On 6/26/2008 4:23 PM, Brian E Carpenter wrote: Lakshminath, On 2008-06-26 23:43, Lakshminath Dondeti wrote: On 6/25/2008 2:41 PM, Brian E Carpenter wrote: ... Our fundamental collective job is defined in RFC 3935: The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. That means that it is *not* our collective job to ensure that a WG consensus survives critical review by the IETF as a whole and by the IESG, if there's reason to believe that the IETF as a whole doesn't agree with the WG consensus. And it's clearly the IESG's job to ensure that the critical review and final consensus (or lack of consensus) occur. But, surely the WG consensus counts as part of the overall IETF consensus process, doesn't it? Please see the example in my response to Jari. The shepherding AD (or at least the document shepherd) has an idea of the WG consensus as well as the IETF consensus. We cannot simply weigh the latest opinions more than all the discussions that have happened as part of the WG consensus. At one level I agree. But suppose that the set of people who are active in the SXFG7M WG are so focused on the sxfg7m protocol that they have all missed the fact that it's extremely damaging to normal operations of the m7gfxs protocol? And this includes the responsible AD, who has no deep knowledge of m7gfxs? This is the sort of problem that IETF Last Call and IESG review is intended to find, and it may well mean that the WG consensus ends up being irrelevant to the IETF non-consensus. (I'm not in the least suggesting that this applies to the draft that led to the appeal that led to this thread.) For what it's worth, I am not talking about a specific draft or a specific WG at this point. I am of the opinion that we are not discussing a one-off issue. If protocol X disrupts protocol Y, we get into very interesting situations. It is also going to get us into a rathole that I want to avoid. My point was this: if a WG actually missed anything substantial and that comes out during an IETF last call, and the shepherding AD agrees, the document gets sent back to the WG. If the shepherding AD also misses or misjudges, any member of the IESG can send it back to the WG for resolution. What I think is not acceptable is for the author and one or more DISCUSS ADs to hack up the document and publish it. If it so happens that the issue raised was considered and ruled out as a non-issue by the WG, then the shepherding AD knows the situation already. Strong consensus in the working group damaging a protocol that matters to very few people (ok, that's a rathole) -- but here is where judgment is necessary. And as you note, any of the judgment calls are appealable. regards, Lakshminath My conclusion, again, is that in the end this is the sort of judgment call that we *expect* the IESG to make. And when we feel they've misjudged, we appeal, and that tunes their judgment for the future. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
On 6/26/2008 6:35 PM, SM wrote: At 04:43 26-06-2008, Lakshminath Dondeti wrote: But, surely the WG consensus counts as part of the overall IETF consensus process, doesn't it? Please see the example in my response to Jari. The shepherding AD (or at least the document shepherd) has an idea of the WG consensus as well as the IETF consensus. We cannot simply weigh the latest opinions more than all the discussions that have happened as part of the WG consensus. The document may be a product of WG consensus. It still has to pass through the community and the IESG to be published as an IETF document. The WG knows about the internals of the document and generally have a focused view. The last call allows a wider range of input and to gauge the impact the proposal may have in other areas. It is not about weighing the latest opinions more. The author/shepard can always post an explanation. The participants in the WG should be aware that there will be an IETF-wide last call. You cannot blame the process if they choose to remain silent instead of taking part in the last call. Note that letter-writing campaigns in a last call have been proven to be ineffective. Is it really necessary for all the battles to repeat on the IETF list? Why can't the shepherding AD judge the overall consensus? thanks, Lakshminath Regards, -sm ___ 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: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
Lakshminath: Consider a hypothetical case: a large WG has strong consensus on one of their documents, they believe it is within the charter's scope and think that the document is in the best interest of the Internet. The WG chairs assess the consensus, and forward the document to the shepherding AD. The shepherding AD takes one last look, determines everything is in order and sends it to last call. A few people on the IETF Discussion list think that the proposed specification is about to doom the Internet. A few others who have not even read the document agree based on emails. Most of the WG members are either not on the IETF list or choose to stay silent. The shepherding AD considers those comments, thinks that those issues have been addressed already and puts the document on the IESG agenda. All other ADs (except one) think that everything is fine and vote No Objection. One AD agrees with the few people on the IETF Discussion list and decides to put a DISCUSS and proceeds to hack the document. In the current model, other than the very few exceptions cited recently, the AD gets what he or she wants for the most part. It is plausible that AD may do this even if no one else identified a problem. Actually, this sounds very similar to the case where an override vote was almost used. Scheduling the override vote was sufficient for the DISCUSS-holding AD to ask for a strawpoll, and based on those results, the DISCUSS-holding AD cleared the DISCUSS position. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: SHOULD vs MUST
Dave, Scott Brim wrote: My rule of thumb is: when you're writing the draft if something is not a MUST, ask yourself why not? and write down your answer. You can be brief but make it clear that the SHOULD is a MUST with exceptions. This gets to an essential issue with IETF specification writing, as well as suggesting some of the distinction between MUST and SHOULD. (By the way, I hope folks are clear that IETF use of these words as normative does not depend upon the case that is used?) This is NOT true. These terms are explicitly defined in all capital letters to make it possible to distinguish when they are being used as normative and when they are not. One of the things RFC authors need to be careful about is to ensure that they do capitalize these terms consistently. In text that is not meant to be normative, the special terms should be avoided - even in lower case - but this can lead to exceptionally stilted use of the English language. -- Eric ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-art review of draft-ietf-rmt-bb-norm-revised-05.txt
Elwyn, Thank you. I have incorporated your editorial notes below into the xml source. best regards, Brian Adamson [EMAIL PROTECTED] On Jun 27, 2008, at 3:04 PM, Elwyn Davies 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-rmt-bb-norm-revised-05.txt Reviewer: Elwyn Davies Review Date: 27 June 2008 IESG Telechat date: 3 July 2008 Summary: Ready. This update has addressed all the issues I raised in my LC review excellently. There are a couple of new and a couple of legacy editorial nits Editorial: s2.4: s/specify use/specify use of/ s3.2.3.1, para 1, last line: s/provided/providing/ s8: s/George, Gross/George Gross/? s5, 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
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Jun 27, 2008, at 3:21 PM, SM wrote: Hi David, At 11:51 27-06-2008, David Conrad wrote: I believe an RFC that provides an IETF-defined list of names (beyond the 4 in 2606) and/or rules defining names the Internet technical community feels would be inappropriate as top-level domains would be quite helpful. Do you mean as in RFC 3675? Well, I can't speak for David, but that was not really what I was thinking of, or what I think the people I was discussing this were thinking. I was thinking of things like .local, which could cause problems if they were given out. Regards Marshall Regards, -sm ___ 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 of RFC 2606 based on the recent ICANN changes ?
Hi, On Jun 27, 2008, at 12:21 PM, SM wrote: I believe an RFC that provides an IETF-defined list of names (beyond the 4 in 2606) and/or rules defining names the Internet technical community feels would be inappropriate as top-level domains would be quite helpful. Do you mean as in RFC 3675? No. I feel an RFC that creates a list (or defines a rule) that identifies what names would be inappropriate for top-level domains would be quite helpful. A couple of examples: - a label consisting of all numbers - the label local There may be others... Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On 27 Jun 2008, at 15:57, David Conrad wrote: On Jun 27, 2008, at 12:21 PM, SM wrote: I believe an RFC that provides an IETF-defined list of names (beyond the 4 in 2606) and/or rules defining names the Internet technical community feels would be inappropriate as top-level domains would be quite helpful. Do you mean as in RFC 3675? No. I feel an RFC that creates a list (or defines a rule) that identifies what names would be inappropriate for top-level domains would be quite helpful. Personally, I think that any such list (even one that was not static, but existed in the form of an IANA registry) would always be incomplete. A better approach, I think, would be for proposed TLDs to pass technical review through some suitable body who could consider each case on its merits. A couple of examples: - a label consisting of all numbers - the label local There may be others... There will always be others, in my opinion, which is why I think the idea of a list of bad ideas is dangerous. Just because things are not on the list of bad ideas doesn't mean they are good ideas, but that's now how people will interpret it. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Update of RFC 2606 based on the recent ICANN changes ?
Just register .local and do not assign it in the same way that 10.x.x.x and 192.168.x.x are registered. From: [EMAIL PROTECTED] on behalf of Joe Abley Sent: Fri 6/27/2008 4:31 PM To: David Conrad Cc: SM; ietf@ietf.org Subject: Re: Update of RFC 2606 based on the recent ICANN changes ? On 27 Jun 2008, at 15:57, David Conrad wrote: On Jun 27, 2008, at 12:21 PM, SM wrote: I believe an RFC that provides an IETF-defined list of names (beyond the 4 in 2606) and/or rules defining names the Internet technical community feels would be inappropriate as top-level domains would be quite helpful. Do you mean as in RFC 3675? No. I feel an RFC that creates a list (or defines a rule) that identifies what names would be inappropriate for top-level domains would be quite helpful. Personally, I think that any such list (even one that was not static, but existed in the form of an IANA registry) would always be incomplete. A better approach, I think, would be for proposed TLDs to pass technical review through some suitable body who could consider each case on its merits. A couple of examples: - a label consisting of all numbers - the label local There may be others... There will always be others, in my opinion, which is why I think the idea of a list of bad ideas is dangerous. Just because things are not on the list of bad ideas doesn't mean they are good ideas, but that's now how people will interpret it. Joe ___ 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
Outage Update
Last night, an extreme spam run caused TMDA to overflow the IETF server and as a result, we experienced an outage for approximately an hour and a half. Unfortunately, two mailing lists were damaged by this outage - the IETF Discussion list, and the SIP list. The databases have been rebuilt from recent backups; however, at your convenience, you should check your subscriptions to those lists. Fortunately, there is some good news. The TMDA replacement system, which has been under development since the first server outage, was installed yesterday. Testing is underway and, within the next day or so, the replacement system will be activated and TMDA will be removed. This should finally put the ongoing stability issues to rest. In addition, we are still moving forward with the split of web and email services on a multiple-server structure; we expect to switch over to the new setup right after IETF 72 in Dublin. Please feel free to contact me if you have any question or concerns. Regards, Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: [EMAIL PROTECTED] Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Joe, On 2008-06-28 08:31, Joe Abley wrote: On 27 Jun 2008, at 15:57, David Conrad wrote: On Jun 27, 2008, at 12:21 PM, SM wrote: I believe an RFC that provides an IETF-defined list of names (beyond the 4 in 2606) and/or rules defining names the Internet technical community feels would be inappropriate as top-level domains would be quite helpful. Do you mean as in RFC 3675? No. I feel an RFC that creates a list (or defines a rule) that identifies what names would be inappropriate for top-level domains would be quite helpful. Personally, I think that any such list (even one that was not static, but existed in the form of an IANA registry) would always be incomplete. A better approach, I think, would be for proposed TLDs to pass technical review through some suitable body who could consider each case on its merits. I think all the external evidence is that ICANN is deeply reluctant to set up mechanisms that require the application of common sense (a.k.a. judgment) as to whether or not a particular domain name may be registered. I see no reason to expect this to be different now they have opened the floodgates to greed at the TLD level too. So I think that any such technical review process is doomed. The best we can do is proceed under the second paragraph of section 4.3 of RFC 2850, i.e. designate specific TLDs as reserved for technical reasons, and so instruct IANA. Furthermore, I believe this is not only the *best* we can; it's essential that we do so, although translating 'example' into every script and language may be going a bit too far. So I believe that 2606bis is very necessary. A couple of examples: - a label consisting of all numbers - the label local There may be others... There will always be others, in my opinion, which is why I think the idea of a list of bad ideas is dangerous. Just because things are not on the list of bad ideas doesn't mean they are good ideas, but that's now how people will interpret it. Unfortunately that's true, and that may mean cranking 2606bis repeatedly. But the alternative (inserting the IETF in a TLD approval process) is pure lawyer-bait and would no doubt send the IETF's insurer apoplectic. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Jun 27, 2008, at 3:22 PM, SM wrote: It would cause problems if .local was given out. I don't recall seeing any RFC requesting IANA to reserve it. Right. - a label consisting of all numbers We already have 888.com. Some users may ask for .888 given its significance in some cultures. A TLD of all numbers would be a real pain to deal with. That is, from a software parsing perspective, what's the difference between the domain name 127.0.0.1 and the IP address 127.0.0.1? I cannot find a technical reason against PAYPAI.c0m. Right. There is a policy reason (confusingly similar), but that's not a technical, e.g., protocol reason. If such a technical review process is doomed, then why should the IETF get into defining technical guidelines outside the .example examples? Because, as you've indicated with the .local example above, protocol actions can result in technical justification why a particular label used as a TLD could be problematic. An IANA registry defining these that ICANN can point to and tell applicants no, because it is in the IETF-defined 'bad' list would likely be helpful. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Hi Brian, folks, Having just recovered from the heat in Paris... IIUC, Microsoft would be free to put in an application for .local if it is so all-fired important to them. Also, if I've decoded the slightly delphic comments correctly, the bidding war with Apple might be fun. Finally, the lawyers of Thomson Local Directories in the UK might be interested and raise an objection. I'll believe it has become a problem when the RFP, evaluation and objection process have been -finalised-, the evaluations have been done, and any agreement has been signed. It could take some time...) all the best, Lawrence (speaking personally) On 27 Jun 2008, at 22:39, Brian E Carpenter wrote: I think all the external evidence is that ICANN is deeply reluctant to set up mechanisms that require the application of common sense (a.k.a. judgment) as to whether or not a particular domain name may be registered. I see no reason to expect this to be different now they have opened the floodgates to greed at the TLD level too. So I think that any such technical review process is doomed. The best we can do is proceed under the second paragraph of section 4.3 of RFC 2850, i.e. designate specific TLDs as reserved for technical reasons, and so instruct IANA. Furthermore, I believe this is not only the *best* we can; it's essential that we do so, although translating 'example' into every script and language may be going a bit too far. So I believe that 2606bis is very necessary. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SHOULD vs MUST case sensitivity
On Fri, 27 Jun 2008, Dave Crocker wrote: Eric Gray wrote: (By the way, I hope folks are clear that IETF use of these words as normative does not depend upon the case that is used?) This is NOT true. These terms are explicitly defined in all capital letters to make it possible to distinguish when they are being used as normative and when they are not. Sorry, no. Please re-read rfc 2219. Specifically: These words are often capitalized. The key word is often which means not always which means not required. That quote is taken out of context. Here is the full text: In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119. I read this to mean that the words are often capitalized in many (pre-RFC 2119) documents. I also read the following two statements to mean that the words will be capitalized when following the guidelnes in RFC 2119. The common usage in the IETF is to capitalize the words when used with the meanings in Sections 1-5 of RFC 2119 and to use then in lower case when ordinary English usage is meant. RFC 2119 itself follows this usage (see, e.g., Section 6, Guidance in the use of these Imperatives). //cmh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Do you mean as in RFC 3675? I sometimes wonder how this RFC ever got off the ground. Its a bit of a joke. regards joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Informational RFC to be: draft-ietf-ediint-compression-11.txt
The IESG has no problem with the publication of 'Compressed Data within an Internet EDI Message' draft-ietf-ediint-compression-11.txt as an Informational RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=7693rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-11.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Note to RFC Editor Please add the RFC3932 Section 4 #1 disclaimer: The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. Chris Newman noted that there may be additional security considerations worth noting, in enabling spam. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
