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
