Re: [Detnet] comments on draft-ietf-detnet-oam-framework-06

[Lou Berger <[e-mail]>]

Hi Greg,

     Thanks for the response/update -- please see below.

On 9/27/2022 5:52 PM, Greg Mirsky wrote:
> Hi Lou,
> thank you for the review, comments, and helpful suggestions. Please 
> find my notes and responses inlined below under the GIM>> tag. 
> Attached is the working version of the draft and the diff highlighting 
> all updates.
>
> Regards,
> Greg
>
> On Fri, Sep 23, 2022 at 11:13 AM Lou Berger <[e-mail]> wrote:
>
>     Hi,
>
>     In preparing my shepherd write up, I noticed a few minor/editorial
>     points that should be addressed before submission for publication
>     to the
>     IESG.
>
>     - Number of authors:
>     The IESG requires justification for more than 5 authors listed on the
>     font page.  This document has 6.  Is anyone willing to move to
>     contributor? If not, can you provide a justification for more than 5
>     authors
>
> GIM>> I believe that all authors, in the course of developing this 
> document, provided essential contributions.

The question that needs to be answered in the Shepherd write up is as 
follows:


13. ... If the total number of authors and editors on the front page
     is greater than five, please provide a justification.

Do you want me to just say?

     The authors believe all listed have provided essential 
contributions in the course of developing this document.

Keep in mind the IESG pushes back hard on more than 5 authors. If the 
authors have a stronger justification, can you (authors) provide it.

>
>     - Inclusion of conformance boilerplate (Section 1.3) and conformance
>     language.
>
>     Generally informational documents do not include the conformance
>     boilerplate or related language.  For example, there is none in the
>     DetNet framework, RFC8939.  On the other hand RFC 4377, OAM
>     Requirements
>     for MPLS Networks, does.
>
>     Is there really a need for such in this document? If you do, the
>     scope
>     of the requirement needs to be clear. (E.g, the requirements are on
>     future solutions "DetNet OAM solutions MUST..." or "solutions
>     providing
>     DetNet OAM MUST..."). Or perhaps just a statement to this effect
>     at the
>     end of section 1.3 or start of section 6.
>
>  GIM>>  I propose appending Section 1.3 with the following:
>    The requirements language in Section 6
>    applies to future implementations of DetNet OAM.

How about

The requirements language is used in Section 6 and applies to future 
implementations of DetNet OAM.

>
>     Section 3-5 I really don't see the need for conformance language
>     in this
>     section.
>
> GIM>> Upon reviewing the last paragraph, propose to remove it altogether:
> OLD TEXT:
>    DetNet OAM mechanisms SHOULD allow a fault detection in real time.
>    They MAY, when possible, predict faults based on current network
>    conditions.  They MAY also identify and report the cause of the
>    actual/predicted network failure.
>
>
>     - Section 3.4, s/NOT RECOMMENDED/expected
>
> GIM>> We've discussed this and propose the following update:
>  OLD TEXT:
>    DetNet is not expected to use multiple paths or links, i.e., Equal-
>    Cost Multipath (ECMP) [RFC8939].  As the result, OAM in ECMP
>    environment is outside the scope of this document.
> NEW TEXT
>    DetNet is not expected to use Equal-Cost Multipath (ECMP) [RFC8939].
>    As the result, DetNet OAM in ECMP environment is outside the scope 
> of this
>    document.
>
>
>     - Section 5.2
>     Can you rephrase/clarify the following sentence.  I frankly have
>     no idea
>     what is meant by it:
>
>          We need to provide mechanisms to patch the network
>         configuration.
>
> GIM>> Thank you for pointing out this sentence to us. It is not really 
> related to OAM but seems more in place in a discussion of the 
> management plane. Hence, propose removing the sentence.
>
>
>     That's it!
>
The above all looks good -- thanks!

> GIM>> In the course of addressing your comments, we've come up with 
> several more editorial updates. Please let us know if these are helpful:
> In Section 4:
> OLD TEXT
>    *  per path to detect misbehaving path when multiple paths are
>       applied.
> NEW TEXT
>    *  per path to detect misbehaving path(s) when multiple paths are
>       used for service protection.
>
> In Section 5, prepend the following new text to the first paragraph:
> NEW TEXT:
>    Service protection (provided by the DetNet service sub-layer) is 
> designed
>    to cope with simple network failures, and it mitigates the 
> immediate reaction
>    of the DetNet controller to network events.
>
What about the case where a controller is not used? Do you perhaps mean 
"DetNet Controller Plane"?

Lou

>
>
>     Thank you,
>     Lou
>