Eric:
The IESG Telechat is held every other Thursday at 11:30 Eastern. I
am not usually able to make use of a review that comes in on Thursday
at all. I really need them on the Tuesday before the telechat,
depending on the number of documents on the agenda that week.
The reviews are most useful at IETF Last Call. That way, the authors
have resolved the issues before the IESG Evaluation even starts.
I appreciate the time that you give to Gen-ART. I'm sending these
comments to the whole list so that everyone is aware of the ways that
their contribution can be most effective.
Russ
At 08:10 AM 6/20/2008, Eric Gray wrote:
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
