Re: [CCAMP] Opinions please FW: [Editorial Errata Reported] RFC7139 (3930)

OK, if you think it is stylistic, I can let it go.
I read the original text as saying 
     [RFC7096]
    does not provide the means to signal all the new Signal Types
which is completely true, but also irrelevant because that RFC does not provide
the means to signal *any* signal types.

While we have this cupboard door open: any thoughts on my conversation with
Fatai on his report on the IANA section of 7139?

A

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: 24 March 2014 00:35
> To: adrian@olddog.co.uk; ccamp@ietf.org
> Subject: Re: [CCAMP] Opinions please FW: [Editorial Errata Reported] RFC7139
> (3930)
> 
> Adrian,
>     I have to say that I really think you are making a pure language
> style point.  I personally would not have phrased the original text the
> way it was written, but I try very hard in document reviews to avoid
> pure stylistic changes.  -- In short, I think authors/editors should
> have stylistic latitude, and generally defer to the RFC editor to make
> any required stylistic changes. Of course, this latitude does not extend
> to technical errors or imprecision.  Unless I'm misreading your change,
> I think it is a purely stylistic revision and I'd recommend rejecting it
> as an Editorial errata.
> 
> Of course, had you made this comment before publication I would have
> supported a change (although I would have tweaked the specific language
> slightly.)
> 
> Lou
> 
> PS I think making a habit of discussing errata before verification is a
> good one, no matter who submits the issue.
> 
> On 3/23/2014 6:09 PM, Adrian Farrel wrote:
> > Hi,
> >
> > Before I get into the habit of raising and verifying errata reports myself,
> > could some of you look at this and check that I am right.
> >
> > Thanks,
> > Adrian
> >
> >> -----Original Message-----
> >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> >> Sent: 23 March 2014 22:04
> >> To: zhangfatai@huawei.com; zhangguoying@mail.ritt.com.cn;
> >> sergio.belotti@alcatel-lucent.it; daniele.ceccarelli@ericsson.com;
> >> kpithewan@infinera.com; akatlas@gmail.com; adrian@olddog.co.uk;
> >> lberger@labn.net; dbrungard@att.com
> >> Cc: adrian@olddog.co.uk; ccamp@ietf.org; rfc-editor@rfc-editor.org
> >> Subject: [Editorial Errata Reported] RFC7139 (3930)
> >>
> >> The following errata report has been submitted for RFC7139,
> >> "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport
> >> Networks".
> >>
> >> --------------------------------------
> >> You may review the report below and at:
> >> http://www.rfc-editor.org/errata_search.php?rfc=7139&eid=3930
> >>
> >> --------------------------------------
> >> Type: Editorial
> >> Reported by: Adrian Farrel <adrian@olddog.co.uk>
> >>
> >> Section: 3
> >>
> >> Original Text
> >> -------------
> >>    [RFC4328] describes GMPLS signaling extensions to support the control
> >>    for the 2001 revision of the G.709 specification.  However, [RFC7096]
> >>    does not provide the means to signal all the new Signal Types and
> >>    related mapping and multiplexing functionalities.  Moreover, it
> >>    supports only the deprecated auto-MSI (Multiframe Structure
> >>    Identifier) mode, which assumes that the Tributary Port Number (TPN)
> >>    is automatically assigned in the transmit direction and not checked
> >>    in the receive direction.
> >>
> >>
> >> Corrected Text
> >> --------------
> >>    [RFC4328] describes GMPLS signaling extensions to support the control
> >>    for the 2001 revision of the G.709 specification.  However, as
> >>    described in[RFC7096], that document does not provide the means to
> >>    signal all the new Signal Types and related mapping and multiplexing
> >>    functionalities.  Moreover, it supports only the deprecated auto-MSI
> >>    (Multiframe Structure Identifier) mode, which assumes that the
> >>    Tributary Port Number (TPN) is automatically assigned in the transmit
> >>    direction and not checked in the receive direction.
> >>
> >>
> >> Notes
> >> -----
> >> RFC 7096 is the analysis of pre-existing GMPLS signalling. It does not
contain
> > any
> >> protocol extensions itself, but looks at the mechanisms provided in RFC
4328.
> >>
> >> Instructions:
> >> -------------
> >> This errata is currently posted as "Reported". If necessary, please
> >> use "Reply All" to discuss whether it should be verified or
> >> rejected. When a decision is reached, the verifying party (IESG)
> >> can log in to change the status and edit the report, if necessary.
> >>
> >> --------------------------------------
> >> RFC7139 (draft-ietf-ccamp-gmpls-signaling-g709v3-12)
> >> --------------------------------------
> >> Title               : GMPLS Signaling Extensions for Control of Evolving
G.709
> > Optical
> >> Transport Networks
> >> Publication Date    : March 2014
> >> Author(s)           : F. Zhang, Ed., G. Zhang, S. Belotti, D. Ceccarelli,
K.
> > Pithewan
> >> Category            : PROPOSED STANDARD
> >> Source              : Common Control and Measurement Plane
> >> Area                : Routing
> >> Stream              : IETF
> >> Verifying Party     : IESG
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> >