No, the typical deadline is COB Tuesday, so Russ has time to review things on Wednesday. My understanding was that the telechats are held in the mornings on Thursday, so in the past COB Wednesday had been the deadline.
I have reminded the group of this several times and it's in the review guidelines: http://www.alvestrand.no/ietf/gen/art/review-guidelines.html but I will now add it as regular note on the telechat assignment emails. Thanks, Mary. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Gray Sent: Friday, June 20, 2008 7:11 AM To: Russ Housley; Alexander Vainshtein Cc: Mark Townsley; [email protected] Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-pew3-tdm-control-protocol-extensi-07 Russ, Probably not. Most of the comments would lead to the sort of changes that are not appropriate for Auth48, if any changes were to be considered. I had thought we had until 3 PM EDT for the telechat, and I think I was supposed to have done a review before for IETF Last Call. I had these mostly done earlier, and would have sent in what I had if I had thought I was up against a hard dead-line. The comments would help readability, not fix problems - hence the RFC Editor and IANA can maybe work a bit harder, the average reader will probably complain about the alphabet soup, and the G.711 encoding can probably be googled easily enough - if anyone wants to know. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Russ Housley [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 19, 2008 8:01 PM > To: Eric Gray; Alexander Vainshtein > Cc: Mark Townsley; [email protected] > Subject: Re: [Gen-art] Gen-ART Review of > draft-ietf-pew3-tdm-control-protocol-extensi-07 > Importance: High > > Eric: > > I did not receive this review until the IESG Telechat was over. It > was too late. Based on the message timestamp, the message was sent an > hour after the IESG Telechat began. > > I hope the authors will consider your comments for Auth48. > > Russ > > At 01:33 PM 6/19/2008, Eric Gray 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: Control Protocol Extensions for TDM Pseudo wires March 2008 > > draft-ietf-pwe3-tdm-control-protocol-extensi-07.txt > >Reviewer: Eric Gray > >Review Date: 19 June 2008 > >IESG Telechat date: 19 June 2008 > > > >Summary: > >======= > > > >This draft is nearly ready for publishing as a Proposed Standard > > > >Comments: > >======== > > > >Terminology and Acronyms: > > > >Below is a list of not necessarily well-know acronyms and/or terms > >used in this draft that are not defined there. These are listed in > >the order in which I first encountered them in the draft. > > > >TDM > >MPLS > >PW > >PE > >FEC > >AGI > >SAII > >TAII > >TLV > >T1 > >DS1 > >E3 > >T3 > >DS3 > >CESoPSN > >TDMoIP > >AAL (AAL1, AAL2) > >CAS > >J1 (attachment circuits) > >CEP > >CID > >SAToP > >MTU > >PDU > >VAD > >RTP > >Differential timestamping > >SF > >SSRC > >CE > > > >While it is fairly clear that the authors know what these acronyms > >(or terms) mean, and it is highly probable that a majority of the > >readers do as well, it would help make the draft more readable if at > >least most of these were defined in a specific section - possibly > >including a reference for the cases where they are defined elsewhere, > >either directly or indirectly. Or they could be explicitly expanded > >in the first instance. Some of the acronyms are expanded at some > >point in the draft - though the cases where such expansions occur at > >the first instance of the acronym are not included in the above list. > > > >_______________________________________________________________ > > > >The Abstract should include no references and a minimum of > >(un-expanded) acronyms. > >_______________________________________________________________ > > > >The phrase "G.711 encoding" is used without a reference. > >_______________________________________________________________ > > > >TBA (by) IANA values? There are for places where a value is listed > >as TBA by IANA. Three are listed in an unnumbered table on page 4, > >and another occurs in Figure 1 ("Format of the TDM Options Interface > >Parameter"). It is not absolutely clear that this fourth one is the > >same as the third one in the table on page 4 (though it seems likely > >that it is). In the IANA Considerations section, only 3 values are > >listed as needing to be assigned by IANA. Given that the "TBA by > >IANA" > >values have to be updated (most likely) by the RFC editor, it would > >be helpful if these were given slightly less ambiguous designations. > >_______________________________________________________________ > > > >Out of curiosity, because inquiring minds want to know, why is > >"Structure-Agnostic TDM over Packet (SAToP)", RFC 4553 listed as > >Normative while "Structure-aware TDM Circuit Emulation Service over > >Packet Switched Network (CESoPSN)", RFC 5086 is listed as > >Informative? > >_______________________________________________ > >Gen-art mailing list > >[email protected] > >https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
