Re: [ippm] AD review of draft-ietf-ippm-multipoint-alt-mark-05

[Giuseppe Fioccola <[e-mail]>]

Hi Mirja,
I remember we had a similar discussion also for RFC8321. And I agree with you, this document is borderline between Experimental and Informational.
Anyway we can keep it Experimental and, as you suggested, we can discuss later in the process if it is worth to change.
I will submit the new version including the editorial nits early next week.

Regards,

Giuseppe


________________________________

Giuseppe Fioccola
Mobile: [phone]<tel:[phone]>
Email: [e-mail]<mailto:[e-mail]>


From: Mirja Kuehlewind<[e-mail]<mailto:[e-mail]>>
To: draft-ietf-ippm-multipoint-alt-mark.all<[e-mail]<mailto:[e-mail]>>
Cc: IETF IPPM WG<[e-mail]<mailto:[e-mail]>>
Subject: AD review of draft-ietf-ippm-multipoint-alt-mark-05
Time: 2020-02-21 16:47:33

Hi authors,

I’m ready to request IETF last call for this document. However, I have one question I would like to discuss:

Why is this document experimental? I know that RFC8321 is also experimental, however, that was probably also a borderline decision but in RFC8321 there are at last mechanisms that will be implemented in interoperable protocols, while this document really only describes mechanisms that can be applied based on existed singling. Further if something is experimental, it also good practice to briefly discuss “what the experiment is”. However, I don’t see this approbate here. Therefore for me this document is clearly informational.

As I’m stepping in March, and we are therefore running a bit out of time, I would like to start IETF last call today no matter what. If you read this mail in the next hours and agree to change to Informational, please do so right away and submit a new version. Otherwise I will request IETF last call anyway later today. Given that experimental and informational have the sam maturity level, we can still change the intended status later without having to re-do the IETF last call.

Also, as no normative language is used, please remove the Requirements Language disclaimer and reference to RFC2119 with the next update.

Find below some minor editorial nits that you may want to address now or in a later version!

Thanks!
Mirja


------
Some editorial nits:

1) Based on the RFC Style Guide RFC7322, you cannot use reference in the abstract. It fine to have an RFC named there, just remove the reference. Further I actually think the last sentence is probably not needed at all in the abstract.

2) In Intro:
OLD
"The alternate marking method, as presented until now, …”
NEW
"The alternate marking method, as described in RFC 8321 [RFC8321], …”

3) In Intro:
"Note that additional details about the
   Alternate Marking methodology are described in the paper
   [IEEE-Network-PNPM]”
Is this sentence really needed? Should the spec in RFC8321 be complete?
(Note that the dot at the end of the sentence is also missing)

4) In Intro:
s/BUM (Broadcast Unknown Unicast Multicast)/BUM (Broadcast, Unknown-unicast, and Multicast)/

5) sec 8.2.1:
s/if we would perform a delay measurement/If we would perform a delay measurement/

6) sec 8.2.2:
s/that don't match/that do not match/

9) sec 9
s/flexibility to PM/flexibility to Performance Management (PM)/