Re: [Gen-art] Mail regarding draft-ietf-opsawg-mpls-tp-oam-def

[Scott Mansfield <[e-mail]>]

Attached are the results of the session I had with Adrian to review the comments against the soup draft.  Please review and ensure the comments have been sufficiently addressed.

Regards,
-scott.

http://tools.ietf.org/html/draft-ietf-opsawg-mpls-tp-oam-def-09
Draft-ietf-opsawg-mpls-tp-oam-def-10 (not yet posted)
Diff_soup_09_10:  A side-by-side diff with the current draft (09)

Proposed resolutions are below (to emails from Adrian and Scott Brim)

Adrian's mail with resolutions in-line:

> > > Repagination shows that this is really just an 8 page document not 
> > > the 14 that it appears. I think some pruning could usefully be 
> > > done to make it even shorter.

Set <?rfc compact="yes"?> option so we now have an 8 page document that is actually an 8 page document.

> > >
> > > 1. What value does the long list of "wrong" OAM expansions in 
> > > Section 1 serve?

The list of acronym expansions has been shortened and moved to a new section that specifically talks about how the OAM term has been used in IETF RFCs.  A reference to each usage is given for illustration.

> > >
> > > 2. Section 2.1 immediately lapses into a discussion of different 
> > > interpretations of "OAM" in the source material of other SDOs. 
> > > This has some interest in qualifying that the problem exists in 
> > > other SDOs as well as in the IETF, but nothing in this section 
> > > seems to have relevance to the purpose of the document or to the 
> > > IETF scope. I wonder about the value of this whole section.
> > >
> > > ---

Section 2 has been reorganized to be a discussion on the "pre-existing uses of OAM" and there is a section for the IETF and for other SDOs.

> > >
> > > The main purpose of the document is clear from the first paragraph 
> > > of the Introduction:
> > >
> > >    The main purpose of this document is to provide a definition of
> > the
> > >    OAM acronym such that it is useful for the IETF.
> > >
> > > But the document does not say *why* this objective is worthwhile.
> > >

By removing the long list of acronym expansions from the Introduction, the section now is clearer on why the objective is worthwhile.

> > > ---
> > >
> > > Section 2.1 says:
> > >
> > >    However there is some ambivalence in the definition and scope 
> > > of the
> > >    term "Operation".
> > >
> > > This may be true, but as it stands no context or explanation is 
> > > given, and so the sentence is not helpful.
> > >
> > > ---

After a short discussion, it was decided that the sentence points out an important aspect of the problem (that the term can have different meanings in different contexts).

> > >
> > > An alternative to consider, even at this late stage, is to move 
> > > the recommended acronym expansions into 
> > > I-D.ietf-opsawg-oam-overview and scrap this document.
> > >
> > >

As Adrian points out in the email below, the IESG has decided to go ahead with pursuing publication for this draft.

Scott Brim's comments (resolutions in-line)

> Document: draft-ietf-opsawg-mpls-tp-oam-def-09
> Reviewer:  Scott Brim
> Review Date:  12 April 2011
> IETF LC End Date:  20 April 2011
> IESG Telechat date: (if known)
> 
> Summary:  Not ready for publication as a BCP
> 
> Major issues:
> 
> The goal is good, but imho the draft is poorly organized, 
> with the result that it does not achieve its purpose well.
> 
> - Give Section 2 a more informative title -- the content appears to be
>   a section on how O, A and M are used in other SDOs, by way of
>   introduction, but the title does not say so.

Section 2 has been renamed and the sub-sections have been repurposed.  Section 2 is now "Pre-existing uses of OAM".  Section 2.1 is "Uses of OAM in other SDOs", and Section 2.2 is "Uses of OAM in the IETF".

> 
> - In Sections 2.2.1 and 2.2.2, no IETF recommendations or
>   disambiguation are included.  That's find.  However, Section 2.2.3
>   makes recommendations.  The decision to use M to mean "maintenance",
>   and what "maintenance" actually means should be moved to Section 3
>   (titled "Recommendations" in fact).  Having a recommendation mixed
>   in with a survey of other usage is confusing to the reader.

The "forward referencing" which was confusing in this section has been removed.

> 
> - There should be another section after Section 4, a follow-up to
>   Section 2, a discussion section to show how the IETF usage differs
>   from that in other SDOs.  Otherwise, what's the point of Section 2?
>   It sets the stage by showing the problem ... but then all that
>   scenery is abandoned.

This is now handled in Section 2.2.  The long list of expansions was removed from the introduction and a concise list (with references to the IETF RFCs) was added to section 2.2.

> 
> - One of the justifications for the recommendation is that OAM
>   including maintenance is "horizontal" (on-path) while management is
>   "vertical" (element - element mgr).  That's a good distinction.
>   However, the "administration" as defined in Section 3 is "vertical".
>   Perhaps based on the draft's own justification, OAM should _not_
>   include "administration" and just be defined as "operations and
>   maintanence"! ... but we don't want that outcome, so I suggest
>   reworking the justification to avoid logical inconsistency.

The paragraph on vertical vs. horizontal was removed mainly because we state in the document that we are not going to define "management" in this draft.  By removing the section the confusion should be eliminated.


> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Thursday, April 28, 2011 1:00 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Mail regarding draft-ietf-opsawg-mpls-tp-oam-def
> 
> Hi,
> 
> During today's telechat we reached the position that the IESG 
> *do* want to publish this document.
> 
> We need to address Scott Brim's review comments and my comments.
> 
> At that time, Pete will look again and decide whether to 
> clear or abstain.
> 
> Scott (Mansfield) is the pen-holder, I think. I'd like to 
> work with you to resolve this with the least amount of work 
> for you. Fancy a phone call to discuss the changes?
> 
> Cheers,
> Adrian
> 
>