Re: What RFC 2460 means
(front posting for quicker reading) I don't recall this being discussed in the IPv6 WG for a long time, but if clarification of intent is needed, that's where it should happen. RFC 2780 explicitly doesn't leave this in IANA's hands. I agree that it affects the exact level of prudence needed in prudent management of a namespace. However, this was not a factor in the IESG discussion. Brian John C Klensin wrote: --On Wednesday, 06 July, 2005 20:37 -0400 John Leslie [EMAIL PROTECTED] wrote: John C Klensin [EMAIL PROTECTED] wrote: --On Wednesday, 06 July, 2005 17:28 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: [Robert Elz wrote:] It isn't really that bad, the option with 17 in the low 5 bits and 0 in the upper 3 is a different option than the one with 17 in the low 5 bits and 7 in the upper 3. So, really there are 8 distint groups of 32 options each. Well, that is not how I read the text in RFC 2460. It's pretty clear to me that there are only 32 option codes and that the other three bits don't extend the code space, but rather they modify the meaning of the 32 basic options. (e.g. the same option can have a hop-by-hop flavour and an e2e flavour). Please set aside, at least temporarily, the issues that got us to this point. It seems to me that, if you and kre, both of whom have considerable experience reading these sorts of documents, can't agree on what 2460 means and how these bits are to be interpreted, we have a really urgent need for some clarification. Can you get the appropriate AD to sign up for that job and get it assigned to a WG as appropriate? It's rare that I find myself disagreeing with John Klensin, but in this case I must. The clarification is already done, at: http://www.iana.org/assignments/ipv6-parameters Section 5b makes it clear that IANA considers Option Types to be eight bits, and is assigning eight-bit values. As a temporary policy, they are currently assigning unique values in the 5-bit rest subfield. We should consider IANA fully competent to interpret this issue, and IMHO it would be wrong for IESG to ask anyone to second-guess IANA here. Well, we don't disagree about that, although I should have taken the extra time to read IANA's interpretation and didn't do so, for which I apologize. However, IANA doesn't make these policies up -- they get them from the IETF, generally with IESG signoff (here presumably on the basis of the text in the IPv6 spec, which went through all of the usual Last Call procedures). However, in the last week or ten days, we have had at least two separate IESG members claim that this really is a five-bit field, with those first three bits being either irrelevant or qualifying (flavor) modifiers as Brian suggests above. So someone is confused. I am pleased that it appears to not be IANA or the IPv6 WG. But, to the extent to which the IESG made its decision on the assumption that the code space here was five bits rather than some larger number (I suspect that, in practice, the interpretations of the first three bits is such that the entire 255 code points cannot be used), then it may be appropriate to review both the decision itself and the question of where that confusion came from. Independent of the other flaws and issues in my I-D (as I have told others, I was serious about its being posted as a focus for discussion -- there are details in it with which I don't agree), this difference of opinion is one of the reasons why it is important to be clear which decisions are being made on an assumption of scarcity and which are not influenced by that consideration. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA considerations
John Klensin wrote: That said, I think we should be paying careful attention to Bruce's implied suggestion about how template boilerplate-generators should be constructed. Some clarification: 1. In the specific case of the troff/nroff rfc macros and template, Ned's characterization of the text as boilerplate is inaccurate. True boilerplate (IPR boilerplate, Copyright notices, Status of this Memo, RFC-Editor funding Acknowledgment, even the canned versions of IESG notes) are contained in the macro package, not visible in an author/editor's source document and not emitted until the document is formatted. The template is provided as a convenience for authors/editors, and has some template text corresponding to the basic recommended RFC structure, some hints on how to do things such as include text that is present in a draft but disappears in RFC form (e.g. a draft change history), etc. An author/editor is of course free to ignore the template completely, using the macros with a source document created from scratch, or modified from another source document. The case might well be different for other means of generating drafts and RFCs, where a boilerplate characterization might be apropos, but it is not in this instance. Placeholder would be a suitable term. 2. I posted what I had put in the template; others are of course free to do nothing at all, to do something completely different, to do something similar, or even to use the same text verbatim (it is not copyrighted). I added the ...presence of this template text... part about 3 weeks ago during early parts of this discussion. I thought it was a reasonable thing to do at the time, and I still think so (if anything, I might be inclined to remove or comment out the no IANA considerations text, which is in fact suggested wording for that specific case and it appears on a single source line with the other text (so failure to edit gets the whole thing, and explicit action is required to make any change, whether that's to remove the warning or to substitute real considerations). I'm not presuming to suggest that others should do likewise. They are free to do so, but to the extent that some people think that I'm some sort of whacko, they might be inclined to do something contrary, and they are of course also free so to do. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Date: 2005-07-06 21:12 From: Bill Strahm [EMAIL PROTECTED] I actually would prefer IANA Considerations This section left intentionally blank That contains at least one certain inaccuracy: it's there, which contradicts left ... blank. Unless you have a bulletproof way of ascertaining intentions (as opposed to apathy, petulance, and/or laziness), it may contain an additional inaccuracy. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Date: 2005-07-06 14:43 From: Ned Freed [EMAIL PROTECTED] This opens the door to the author forgetting to check and the various reviewers assuming the prsence of the sections means a check was done. I can't speak for others, but 1. if a draft has no IANA considerations section, idnits will so indicate (but see below), and that's a warning sign to check -- if idnits is run. Of course, one would expect conscientious authors/editors to a) abide by the guidelines (which is where the MUST include an IANA considerations section is specified) b) check against the I-D Checklist c) run idnits but obviously some authors/editors do not do so, and not all reviewers check vs. the Checklist and/or run idnits 2. if a draft has a no IANA considerations text, that certainly prompts this reviewer to check that statement for accuracy At the moment (see below), that means that if there is no IANA considerations section at all, idnits will flag that fact and if there is such a section it will be reviewed; either way *seems* to result in review of the draft w.r.t. IANA considerations. I suppose. That said, if IANA considerations was *not* built into the boilerplate, it would have a high likelihood of being omitted. Which would then be noted on checklist review, causing a fairly careful check to be made to see if there really aren't any considerations to be listed in such a section. Unless I misunderstood your earlier comments, Ned, you suggested that the requirement should be dropped. Which would presumably mean that the idnits check against that requirement would be dropped, and then there would be the very real possibility, nay probability, that a draft with no IANA considerations section would get through review even if there is something that should be addressed by IANA. And that is precisely why several people have been advocating the rule, namely that it prompts review of the issue (whether or not a particular author/editor adheres to the rule). Indeed, although BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section, many documents do not include one even where internationalization is an issue. If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. That is another matter, as is whether or not a published RFC should contain a null internationalization considerations section. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the IESG rule or not? and all that...
Joe, Joe Touch wrote: Keith Moore wrote: Keith, The IESG can still exercise their best engineering judgment as individuals, as the rest of us do. The IESG role itself need not incorporate a privileged position from which to wield that judgement. There's plenty left to do. Joe, The IESG has several duties that are defined in RFC 2026 and other documents. These duties include using engineering judgment to determine whether documents meet criteria for standards track, or whether to bless certain kinds of protocol extensions. All this notion of privilege misses the point - which is that we cannot ensure document or protocol quality without having some set of people decide whether or not a proposal is good enough. Re-reviewing 2026, in all places the IESG is noted as being largely reactive to the community and guiding process. Only sec 6.1.2 notes the application of technical judgement, but only regarding maturity of the document and the standards level being sought - specifically as technical quality and clarity. It specifically notes that (emphasis mine) _independent_ technical review can be solicited if there are issues of its impact on the Internet architecture. You are quoting very selectively. The context is rather different from what you imply: In order to obtain all of the information necessary to make these determinations, particularly when the specification is considered by the IESG to be extremely important in terms of its potential impact on the Internet or on the suite of Internet protocols, the IESG may, at its discretion, commission an independent technical review of the specification. In other words, the IESG gets to make the judgement call, but may choose to get an independent review. This happens. As a matter of fact, I do it every two weeks for all the drafts on the agenda, and Harald did it before me. It's all public, see http://www.alvestrand.no/ietf/gen/art/gen-art.html. Right now, the IESG is conducting its own, non-independent technical review - therein lies the issue, IMO. It's very clear that RFC 2026 sets the IESG up as the reviewer of last resort (modulo the appeal process). I really don't understand your issue except perhaps as a criticism of 2026. If the IESG isn't to be the reviewer of last resort, who should it be? If IESG people were to personally benefit from their exercise of this privilege you'd have a valid gripe. Personal gain is not the only motive; power can be its own motive. The gripes are validated by cases of abuse of privilege. Others have raised a few such cases, e.g., where individuals didn't recuse themselves from process when they had personal interest in the outcome of a doc. I don't recall any such case being raised. Can you point to the relevant messages in the archive? But I don't recall ever seeing this happen. If it does happen, I don't think it happens very often. Neither are reasons not to prohibit it or address it when it occurs. Conflict of interest is covered in RFC 3710 (which isn't a BCP, as it was a first cut). Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the IESG rule or not? and all that...
Brian E Carpenter wrote: Joe, ... Re-reviewing 2026, in all places the IESG is noted as being largely reactive to the community and guiding process. Only sec 6.1.2 notes the application of technical judgement, but only regarding maturity of the document and the standards level being sought - specifically as technical quality and clarity. It specifically notes that (emphasis mine) _independent_ technical review can be solicited if there are issues of its impact on the Internet architecture. You are quoting very selectively. The context is rather different from what you imply: In order to obtain all of the information necessary to make these determinations, particularly when the specification is considered by the IESG to be extremely important in terms of its potential impact on the Internet or on the suite of Internet protocols, the IESG may, at its discretion, commission an independent technical review of the specification. In other words, the IESG gets to make the judgement call, but may choose to get an independent review. This happens. As a matter of fact, I do it every two weeks for all the drafts on the agenda, and Harald did it before me. It's all public, see http://www.alvestrand.no/ietf/gen/art/gen-art.html. Right now, the IESG is conducting its own, non-independent technical review - therein lies the issue, IMO. It's very clear that RFC 2026 sets the IESG up as the reviewer of last resort (modulo the appeal process). I really don't understand your issue except perhaps as a criticism of 2026. If the IESG isn't to be the reviewer of last resort, who should it be? An independent body - one that doesn't get to decide the importance of its own review. Perhaps it is a criticism of 2026 if there are so many varying interpretations. ... Conflict of interest is covered in RFC 3710 (which isn't a BCP, as it was a first cut). Asking people to recuse themselves for conflict of interest is very different from not putting the decision in front of them. While the former is always required, it doesn't avoid the utility of the latter. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term IESG approval (Re: IANA Action: Assignment ofan IPV6 Hop-by-hop Option)
Date:Wed, 06 Jul 2005 17:28:28 +0200 From:Brian E Carpenter [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Well, that is not how I read the text in RFC 2460. It's pretty clear | to me that there are only 32 option codes and that the other three bits | don't extend the code space, but rather they modify the meaning of the | 32 basic options. (e.g. the same option can have a hop-by-hop flavour | and an e2e flavour). I'm glad that John Leslie pointed out that IANA isn't interpreting it that way, which would be truly wild. What 2460 says is ... The three high-order bits described above are to be treated as part of the Option Type, not independent of the Option Type. That is, a particular option is identified by a full 8-bit Option Type, not just the low-order 5 bits of an Option Type. I have no idea how you manage to interpret identified bt a full 8-bit Option Type, not just the low-order 5 bits in the way you say you do, but if that text isn't clear enough for you, I have no idea what could possibly be, and perhaps we should just stop talking about anything that relates to interpretation of the documents, as it seems likely to just be a waste of time. On the parenthetcal comment at the end of your message - yes, of course an option can be both e2e and hbh, in fact, that's the normal case, the options registered apply to both hbh dst opt headers (though a particular option can be defined to have meaning only in one of those situations, Router Alert as an e2e option would be a fairly meaningless thing...) What's more relevant here is how you're managing to convolute the e2e/hbh issue, with the top 3 bits of the option code? They're orthogonal. None of the top 3 bits have anything at all to do with which header the option appears in (though the 0x20 bit being set in an e2e opt header takes a little bit of understanding to appreciate how it can apply - don't just assume it cannot, it certainly can, but it isn't going to be common) In any case, for John Klensin, there's no need to waste time clarifying this, it is already just about as clear as it is possible to write it. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
Date:Tue, 05 Jul 2005 11:32:12 +0200 From:Brian E Carpenter [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Also remember that no consensus in an issue like this, really needs to | mean no authority - if you cannot get at least most of the community to | agree with the IESG position, then the IESG cannot just claim the | authority and say there is no consensus that we should not have it. | | I don't believe that is true in this case, as long as RFC 2780 is in force. | Especially since there is a clear path for Larry Roberts to ask for | IETF consensus, which by definition would overrule the IESG. 2780 has nothing to do with it. No-one is disputing what 2780 says. The question is what the words in 2434 (to which 2780 refers) actually mean. To me, and apparently to some others, it is clear that 2434 is all about what amount of documentation is required to get IANA to register an option, and who gets to judge that documentation. There's no suggestion in 2434 that anything else should be subject to scrutiny. Read the whole doc, not just the two sentences that directly apply in isolation. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
I suppose. That said, if IANA considerations was *not* built into the boilerplate, it would have a high likelihood of being omitted. Which would then be noted on checklist review, causing a fairly careful check to be made to see if there really aren't any considerations to be listed in such a section. Unless I misunderstood your earlier comments, Ned, you suggested that the requirement should be dropped. I have never suggested that the requirment for an IANA considerations section in documents that contain IANA considerations be dropped. Nor have I ever suggested that review for IANA considerations be dropped. On the contrary, such review is essential. Which would presumably mean that the idnits check against that requirement would be dropped, On the contrary, it is important that automated tools warn that such sections are missing. This warning should not prevent a document from being last called, however. and then there would be the very real possibility, nay probability, that a draft with no IANA considerations section would get through review even if there is something that should be addressed by IANA. Doesn't follow. And that is precisely why several people have been advocating the rule, namely that it prompts review of the issue (whether or not a particular author/editor adheres to the rule). I disagree. I think it will over time come to have exactly the opposite effect. Indeed, although BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section, many documents do not include one even where internationalization is an issue. If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. That is another matter, as is whether or not a published RFC should contain a null internationalization considerations section. Sigh. More boilerplate BS, more unnecessary nonsense, more disincentives for authors, less and lower quality review, and fewer and poorer documents. This is absolutely the wrong path for us to be on. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Resolution of last call comments for draft-harris-ssh-arcfour-fixes-02.txt
On Wed, 29 Jun 2005, Sam Hartman wrote: Please add an applicability statement discussing the performance advantages of RC4 against the known security weaknesses. You may end up reusing text from your security considerations text. Your applicability statement needs to suggest to the reader that they consider the ssh newmodes draft as an alternative to your rc4 ciphers. This alternative should be chosen in environments where the advantages of RC4 do not make it attractive. I've done this and sent draft-harris-ssh-arcfour-fixes-03.txt to be posted. In addition, I'm still waiting to hear back from you on the questions raised in the security directorate review. While these points are minor, they should be addressed. I've replied to them, removed my dodgy information theory and referenced the relevant recent papers. -- Ben Harris ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Thu July 7 2005 15:32, Ned Freed wrote: I have never suggested that the requirment for an IANA considerations section in documents that contain IANA considerations be dropped. The specific requirement is for the presence of a section in an I-D presented for publication as an RFC even in the case that there are no IANA actions. Which would presumably mean that the idnits check against that requirement would be dropped, On the contrary, it is important that automated tools warn that such sections are missing. This warning should not prevent a document from being last called, however. idnits generates a warning because there is a requirement for such a section. I don't think it is reasonable to expect that an automated tool will be able to determine whether or not IANA actions would be required; it is easy to determine whether or not a section is present. Which is all that should be done. If the unconditional requirement for a section goes away, I would expect the test to go away, or to at least require some non-default option to be specified to enable it. Otherwise it will appear when there are in fact no IANA actions and then it will be treated as noise, like the fabled boy who cried wolf. Then by all means only issue the warning when in let's find out what needs to be reviewed mode. And that is precisely why several people have been advocating the rule, namely that it prompts review of the issue (whether or not a particular author/editor adheres to the rule). I disagree. I think it will over time come to have exactly the opposite effect. The only way to tell for sure is to let the experiment run its course. Early indications are that it is already having the opposite effect. Indeed, although BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section, many documents do not include one even where internationalization is an issue. If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. That is another matter, as is whether or not a published RFC should contain a null internationalization considerations section. Sigh. More boilerplate BS, more unnecessary nonsense, more disincentives for authors, less and lower quality review, and fewer and poorer documents. Not boilerplate, a reminder for authors/editors to consider the issue, and the remainder simply don't follow. I disagree completely. And I believe that further disucssion of this is pointless, so this will be my final note on the topic. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Thu July 7 2005 15:32, Ned Freed wrote: I have never suggested that the requirment for an IANA considerations section in documents that contain IANA considerations be dropped. The specific requirement is for the presence of a section in an I-D presented for publication as an RFC even in the case that there are no IANA actions. Which would presumably mean that the idnits check against that requirement would be dropped, On the contrary, it is important that automated tools warn that such sections are missing. This warning should not prevent a document from being last called, however. idnits generates a warning because there is a requirement for such a section. I don't think it is reasonable to expect that an automated tool will be able to determine whether or not IANA actions would be required; it is easy to determine whether or not a section is present. If the unconditional requirement for a section goes away, I would expect the test to go away, or to at least require some non-default option to be specified to enable it. Otherwise it will appear when there are in fact no IANA actions and then it will be treated as noise, like the fabled boy who cried wolf. And that is precisely why several people have been advocating the rule, namely that it prompts review of the issue (whether or not a particular author/editor adheres to the rule). I disagree. I think it will over time come to have exactly the opposite effect. The only way to tell for sure is to let the experiment run its course. Indeed, although BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section, many documents do not include one even where internationalization is an issue. If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. That is another matter, as is whether or not a published RFC should contain a null internationalization considerations section. Sigh. More boilerplate BS, more unnecessary nonsense, more disincentives for authors, less and lower quality review, and fewer and poorer documents. Not boilerplate, a reminder for authors/editors to consider the issue, and the remainder simply don't follow. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Commenting only on the idnits specific issue here: On 2005-07-07 22:08 Bruce Lilly said the following: On Thu July 7 2005 15:32, Ned Freed wrote: [...] Which would presumably mean that the idnits check against that requirement would be dropped, On the contrary, it is important that automated tools warn that such sections are missing. This warning should not prevent a document from being last called, however. idnits generates a warning because there is a requirement for such a section. I don't think it is reasonable to expect that an automated tool will be able to determine whether or not IANA actions would be required; it is easy to determine whether or not a section is present. Right. If the unconditional requirement for a section goes away, I would expect the test to go away, or to at least require some non-default option to be specified to enable it. Otherwise it will appear when there are in fact no IANA actions and then it will be treated as noise, like the fabled boy who cried wolf. Yes. When http://www.ietf.org/ID-Checklist.html changes, idnits is updated to match. Otherwise, the tool would swiftly become useless. Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Bruce Lilly wrote: BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section Oh, that beast, a MUST UTF-8, not less. Didn't make it into RfC 3912, can I declare it broken by design and return to RfC 954, please ? It took me hours to find RfC 1032 for RFCI. While we're at it, did you see draft-hoffman-utf8-rfcs-00.txt ? OTOH Paul saw no problem to submit some I-Ds without a dummy IANA section - and for gopher I even asked, after all there is this IANA URI scheme registry, they might wish to update it. If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. Maybe. OTOH it wouldn't be polite to write SMTP error texts are i-default US-ASCII, stupid, so that's what you put in an SPF exp= explanation, for more I18N you could use a http URL. Thinking about IANA doesn't upset me, it's rather harmless, just one of the dozens of nits distributed in at least three obscure texts, none of them an RfC. The IPR boilerplate makes me mad, but unfortunately the authors of xml2rfc didn't adopt my ipr=fullmeep or ipr=fulleula proposals. Insert four-letter word for meep. At most three lines pointing to a creative commons BY SA license should be good enough for most I-Ds. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term IESG approval
On Thu, 7 Jul 2005, Robert Elze wrote: The question is what the words in 2434 (to which 2780 refers) actually mean. To me, and apparently to some others, it is clear that 2434 is all about what amount of documentation is required to get IANA to register an option, and who gets to judge that documentation. There's no suggestion in 2434 that anything else should be subject to scrutiny. Read the whole doc, not just the two sentences that directly apply in isolation. I have read the whole doc, and I am unable to understand how you (and those others) come to that conclusion _based on the words that are actually in the document_. Would it be unreasonable to ask that you point to some text in the document to support your claim? Or lacking that, to point to some publically archived discussion (e.g. last call comments) that support your position? Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'IMAP4 ACL extension' to Proposed Standard
The IESG has approved the following document: - 'IMAP4 ACL extension ' draft-ietf-imapext-2086upd-08.txt as a Proposed Standard This document is the product of the Internet Message Access Protocol Extension Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-08.txt Technical Summary The ACL (Access Control List) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol. This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. Working Group Summary The document has been reviewed by key working group members and implementers. Consensus was reached, and there are no known issues risking appeal. Protocol Quality Scott Hollenbeck has reviewed this specification for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4115 on A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic
A new Request for Comments is now available in online RFC libraries. RFC 4115 Title: A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic Author(s): O. Aboul-Magd, S. Rabie Status: Informational Date: July 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 6 Characters: 12131 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-aboulmagd-trtcm-inprofile-02.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4115.txt This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4115.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4130 on MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)
A new Request for Comments is now available in online RFC libraries. RFC 4130 Title: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) Author(s): D. Moberg, R. Drummond Status: Standards Track Date: July 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 47 Characters: 99857 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-ediint-as2-20.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4130.txt This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as AS2 because it is the second applicability statement, produced after AS1, RFC 3335. This document is a product of the Electronic Data Interchange-Internet Integration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4130.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4122 on A Universally Unique IDentifier (UUID) URN Namespace
A new Request for Comments is now available in online RFC libraries. RFC 4122 Title: A Universally Unique IDentifier (UUID) URN Namespace Author(s): P. Leach, M. Mealling, R. Salz Status: Standards Track Date: July 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 32 Characters: 59319 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-mealling-uuid-urn-05.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4122.txt This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4122.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4079 on A Presence Architecture for the Distribution of GEOPRIV Location Objects
A new Request for Comments is now available in online RFC libraries. RFC 4079 Title: A Presence Architecture for the Distribution of GEOPRIV Location Objects Author(s): J. Peterson Status: Informational Date: July 2005 Mailbox:[EMAIL PROTECTED] Pages: 7 Characters: 16718 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-geopriv-pres-02.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4079.txt GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV. This document is a product of the Geographic Location/Privacy Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4079.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
