RE: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP [WAS: Gen-art review of draft-heard-rfc4181-update-00.txt]
Mike's assessment seems reasonable to me. Dan -Original Message- From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 9:36 AM To: C. M. Heard Cc: IETF; Romascanu, Dan (Dan); GEN-ART Subject: Re: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP [WAS: Gen-art review of draft-heard-rfc4181-update-00.txt] Hi Mike, as the review says, they are just nits. If you disagree with them, feel free to ignore them (as long as your AD is also OK with that, of course). Cheers, Gonzalo C. M. Heard wrote: On Tue, 23 Jan 2007, Gonzalo Camarillo 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. I will do so, and in that spirit I'm posting my response to the IETF list with the subject line changed. My apologies for the delay in replying. Draft: draft-heard-rfc4181-update-00.txt Reviewer: Gonzalo Camarillo [EMAIL PROTECTED] Review Date: 23 January 2006 IETF LC Date: 16 January 2006 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: The title of the draft could be more explicit. Now it mentions RFC 4181. It could also indicate that it is an update to the Guidelines for Authors and Reviewers of MIB Documents. I disagree with this comment -- I believe that doing as it suggests would make the title unnecessarily long. Note that the Abstract already spells out the full title of RFC 4181. Acronyms (e.g., MIB) should be expanded on their first use. The only places where the acronym MIB is used are in the Abstract and the References, where the title of RFC 4181 is quoted. The acronym is not expanded in that title, and it would be inappropriate to do so in a citation, which is supposed to quote the exact title of the document being cited. Also, I believe that MIB qualifies as an appreviation that is so firmly extablished in IETF usage that its use is very unlikely to cause uncertainty or ambiguity and so is exempt from the usual acronym expansion requirement. Granted that it is not explicitly mentioned in http://www.rfc-editor.org/policy.html#policy.abbrevs, but several recent RFCs using the acronym MIB have appeared without it being expanded anywhere. RFC 4181 and RFC 4663 are examples. The only other acronym I see is IETF, and that one is explicitly mentioned in http://www.rfc-editor.org/policy.html#policy.abbrevs. The draft should be divided into pages, none of which should exceed 58 lines. Unless I'm required to make another revision for other reasons, I'd like to let the RFC Editor take care of that (which they will do anyway) ... my apologies if the lack of pagination has caused any readability problems. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
About Gen-ART reviews
Hi, As devoted readers may have noticed, quite a few Gen-ART reviews have been copied to this list recently, with follow-up postings in some cases. Is this a good or a bad thing? Comments welcome. Brian (as General AD) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About Gen-ART reviews
Brian, As a recent victim of a Gen-ART review, I can only say that it improved the quality of the RFC-to-be (thanks, Spencer!). And the reviews might encourage other people to read the draft that might not otherwise had a chance to be aware of it. So yeah, keep them coming! Cheers, Andy On 2/13/07, Brian E Carpenter [EMAIL PROTECTED] wrote: Hi, As devoted readers may have noticed, quite a few Gen-ART reviews have been copied to this list recently, with follow-up postings in some cases. Is this a good or a bad thing? Comments welcome. Brian (as General AD) ___ 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: About Gen-ART reviews
Brian, I think it would be a bad thing if it was a general rule. At the level/frequency applied to date, it's a good thing. Thanks! -- Eric Gray Principal Engineer Ericsson -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 7:34 AM To: IETF discussion list Subject: About Gen-ART reviews Hi, As devoted readers may have noticed, quite a few Gen-ART reviews have been copied to this list recently, with follow-up postings in some cases. Is this a good or a bad thing? Comments welcome. Brian (as General AD) ___ 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: About Gen-ART reviews
Andrew G. Malis wrote: As a recent victim of a Gen-ART review, I can only say that it improved the quality of the RFC-to-be (thanks, Spencer!). And the reviews might encourage other people to read the draft that might not otherwise had a chance to be aware of it. So yeah, keep them coming! This was my experience as well (thanks, Elwyn!). Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About Gen-ART reviews
My experience is that Gen-ART reviews are very useful. Whether they need to be posted to this list or not is another question. I think they would be just as useful without the posting, but I like to at least see the initial review. I don't think the issues need to be resolved on this list, however. Mark On Feb 13, 2007, at 5:14 AM, Andrew G. Malis wrote: Brian, As a recent victim of a Gen-ART review, I can only say that it improved the quality of the RFC-to-be (thanks, Spencer!). And the reviews might encourage other people to read the draft that might not otherwise had a chance to be aware of it. So yeah, keep them coming! Cheers, Andy On 2/13/07, Brian E Carpenter [EMAIL PROTECTED] wrote: Hi, As devoted readers may have noticed, quite a few Gen-ART reviews have been copied to this list recently, with follow-up postings in some cases. Is this a good or a bad thing? Comments welcome. Brian (as General AD) ___ 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: About Gen-ART reviews
Mark Baugher schrieb: My experience is that Gen-ART reviews are very useful. Whether they need to be posted to this list or not is another question. I think they would be just as useful without the posting, but I like to at least see the initial review. I don't think the issues need to be resolved on this list, however. +1 Optimally, the review should be sent to the mailing list where the initial spec development took place, as well (there'll alway be one, and in doubt it will be mentioned in the front matter of the document, right :-). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About Gen-ART reviews
I think that Gen-ART reviews should be treated like any other IETF Last Call comments. The reviews themselves are very useful, especially when the assignment causes cross-area review. However, I do not think that the reviews carry the same weight as other IETF Last Call comments. As such, ther should be sent to this list or the iesg@ietf.org mail list or both. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About Gen-ART reviews
At 4:47 PM +0100 2/13/07, Julian Reschke wrote: Mark Baugher schrieb: My experience is that Gen-ART reviews are very useful. Whether they need to be posted to this list or not is another question. I think they would be just as useful without the posting, but I like to at least see the initial review. I don't think the issues need to be resolved on this list, however. +1 Optimally, the review should be sent to the mailing list where the initial spec development took place, as well (there'll alway be one, and in doubt it will be mentioned in the front matter of the document, right :-). +.5 A possible rule-of-thumb would be: If it is all editorial comments, there is no need to sent it to [EMAIL PROTECTED] If there are any suggested changes to the protocol / requirements / whatever, or if the tone is I don't understand what is going on here, send it to ietf@ietf.org so others can see and maybe comment on those suggestions and questions. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About Gen-ART reviews
[Rending after correcting a silly typo...] I think that Gen-ART reviews should be treated like any other IETF Last Call comments. The reviews themselves are very useful, especially when the assignment causes cross-area review. And, I think that the reviews carry the same weight as other IETF Last Call comments. As such, they should be sent to this list or the iesg@ietf.org mail list or both. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About Gen-ART reviews
Brian, My view may be no surprise to you. All reviews (including GenArt) and the subsequent discussions should be copied to *some* mailing list so that the whole process is both public and archived. Copying the WG mailing list would be best, but may be a pain because the reviewer is not usually subscribed and this may introduce delays while postings are authorised (of course, there is nothing to stop the reviewer subscribing). Posting to a GenArt-Review mailing list would be less acceptable because the I-D authors/editors are not usually able to subscribe and would not normally monitor such a list. The main IETF mailing list is a compromise, but not particularly good as it may obscure the other traffic on the list. Adrian - Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: IETF discussion list ietf@ietf.org Sent: Tuesday, February 13, 2007 12:33 PM Subject: About Gen-ART reviews Hi, As devoted readers may have noticed, quite a few Gen-ART reviews have been copied to this list recently, with follow-up postings in some cases. Is this a good or a bad thing? Comments welcome. Brian (as General AD) ___ 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: About Gen-ART reviews
On Tuesday, February 13, 2007 08:33:44 PM + Adrian Farrel [EMAIL PROTECTED] wrote: The main IETF mailing list is a compromise, but not particularly good as it may obscure the other traffic on the list. Oh, yes; it would be a shame if discussion of documents in IETF Last Call caused someone to miss the latest flamefest. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About Gen-ART reviews
Adrian Farrel wrote: The main IETF mailing list is a compromise, but not particularly good as it may obscure the other traffic on the list. I think obscuring the other traffic on this list with information pertinent to the primary purpose of this organization is a good thing. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP [WAS: Gen-art review of draft-heard-rfc4181-update-00.txt]
On Monday, February 12, 2007 10:26:13 AM -0800 C. M. Heard [EMAIL PROTECTED] wrote: The title of the draft could be more explicit. Now it mentions RFC 4181. It could also indicate that it is an update to the Guidelines for Authors and Reviewers of MIB Documents. I disagree with this comment -- I believe that doing as it suggests would make the title unnecessarily long. Note that the Abstract already spells out the full title of RFC 4181. A document title should be meaningful enough that by reading a citation or an rfc-index entry, you can tell what the document is about, at least at a high level. Normally, I'd say that means _not_ naming an updated document only by its RFC number, since that effectively forms a citation within a citation that can be more work to track down than it should be. In this case, I think the essential part is there -- it's an update to recognize the IETF Trust. The last document of this type that I reviewed was RFC4748, and its title is constructed in exactly the same way. I didn't have a problem with it then, and I don't now, either. Acronyms (e.g., MIB) should be expanded on their first use. I have to agree fully with Mike here - MIB is a well-known acronym; in fact, I'd argue that it's so well-known that more people know what it means than know what it stands for. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple)
A modified charter has been submitted for the SIP for Instant Messaging and Presence Leveraging Extensions (simple)working group in the Real- time Applications and Infrastructure Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by February 19th. +++ SIP for Instant Messaging and Presence Leveraging Extensions (simple) == Current Status: Active Working Group Chair(s): Robert Sparks [EMAIL PROTECTED] Hisham Khartabil [EMAIL PROTECTED] Real-time Applications and Infrastructure Area Director(s): Jon Peterson [EMAIL PROTECTED] Cullen Jennings [EMAIL PROTECTED] Real-time Applications and Infrastructure Area Advisor: Jon Peterson [EMAIL PROTECTED] Technical Advisor(s): Jon Peterson [EMAIL PROTECTED] Mailing Lists: General Discussion: simple@ietf.org To Subscribe: [EMAIL PROTECTED] In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work should be socialized with the chairs and AD early to determine if this WG is an appropriate venue. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Goals and Milestones: Done Submission of event package for presence to IESG for publication as Proposed Standard Done Submission of watcher information drafts to IESG for publication as Proposed Standards Done Submission of proposed event list mechanism to the SIP working group Done Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done Submission of proposed mechanism for event publishing to the SIP working group Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done Submission of base XCAP draft to IESG for publication as Proposed Standard Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard Done Submission of XCAP usage for manipulation of presence document content Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done Submission of instant messaging session relay
WG Review: Congestion and Pre-Congestion Notification (pcn)
A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by February 19th. +++ Congestion and Pre-Congestion Notification (pcn) = Current Status: Proposed Wroking Group Chair(s): tbd Transport Area Director(s): Magnus Westerlund [EMAIL PROTECTED] Lars Eggert [EMAIL PROTECTED] Transport Area Advisor: Lars Eggert [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pcn/index.html Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established inelastic flows within a DiffServ domain when congestion is imminent or existing. These mechanisms operate at the domain boundary, based on aggregated congestion and pre-congestion information from within the domain. The focus of the WG is on developing standards for the marking behavior of the interior nodes and the encoding and transport of the congestion information. To allow for future extensions to the mechanisms and their application to new deployment scenarios, they are logically separated into several components, namely, encoding and transport along forward path from marker to egress, metering of congestion information at the egress, and transport of congestion information back to the controlling ingress. Reaction mechanisms at the boundary consist of flow admission and flow termination. Although designed to work together, flow admission and flow termination are independent mechanisms, and the use of one does not require or prevent the use of the other. The WG may produce a small number of informational documents that describe how specific quality-of-service policies for a domain can be implemented using these two mechanisms. The PCN WG will specify the following components to protect the quality-of-service of flows within a DiffServ domain: (1) a general architecture for flow admission and termination based on aggregated (pre-)congestion information (2) a specification of conditions under which interior nodes generate (pre-)congestion information (3) encoding and transport of (pre-)congestion information between the interior and domain egress (4) metering of (pre-)congestion information at the domain egress (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress (6) ingress node control mechanisms for flow admission or termination, based on aggregated (pre-)congestion information The WG focuses on the overall architecture, and specifically on the marking behavior and encoding and transport mechanisms needed to realize it. Standards-track protocols and mechanisms are only developed where necessary for interoperability. For other components of the architecture, the WG may document examples or provide recommended solutions in informational documents. The architecture document will be comprehensive, and include security, manageability and operational considerations. If this WG requires extensions or modifications to protocols that are products of other WGs, it may motivate their need and describe requirements in informational documents; design of such extensions and modifications will take place in the appropriate WGs. The initial scope of the PCN WG is restricted by the following assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ domains, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion information. One example could be flow-rate adaptation (rather than flow admission/termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may consider their requirements to design components that are sufficiently general to support such extensions in the future.
