Re: [rmcat] AD review of draft-ietf-rmcat-sbd-09

[Michael Welzl <[e-mail]>]

Hi,

I’m cutting away some things and only answering on the part that speaks to me as one of the authors:


>>> We believe that Experimental status is more fitting; we looked at the checklist here, from which this seems a pretty clear decision to us:
>>> https://www.ietf.org/standards/process/informational-vs-experimental
> 
> So I would like to add something here. I don't know why you think from this text that experimental is the better fit, but I think both are suitable and therefore I'm also fine to move on with experimental but I wanted to make sure that this has been considered.

1. If it can't be practiced, it's Informational.  => this is an algorithm, it can be practiced.
2. If it's not going to be changed no matter what the result is, it's Informational  => that’s not the case, see my answer below regarding “will never touch it again”.
3. (..)work that could be practiced, was developed in the IETF, has been dropped for some reason, but is being published for the record(..) Informational or Historic  => that’s also not the case.
4. If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental  => again the point below, I do think this can go to standards track after more experience.
5. If the document contains implicit or explicit success/failure criteria, and it's clear that the outcome can be used as the basis for a recommendation to the IETF community, it's Experimental  => well there’s a section on expected feedback from experiments.


> So both informational and experimental do not need to have IETF consensus (but as I said they usually have); so no difference in this aspect. Experimental docs are usually specs that are not ready for proposed standard yet but experimentation in the Internet is needed to move forward. However, sbd is not really a spec, it's more a documentation of a mechansims. As such I think it could also be moved forward as informational.

I don’t see what makes you say that this isn’t really a spec? It should be, it’s meant to be a spec.


> The difference for me at this point is, are there any plans to move it forward to proposed standard as any point in the future, or do we keep this document as a documentation of the proposed mechanism and probably will never touch it again?

Well, it’s certainly my plan as one of the authors to move this forward to proposed standard at some point in the future. We’re actively working on this.


>> Ok, thanks for the feedback Michael. Then we stay with experimental.
> 
> Assuming, we have a decision on the indented status (going for exp as the current version said). Would you like to submit another update before IETF last call, or should I just start the IETF last right away?

We’d like to do another update - there were some recommendations here: removing the reference to coupled-cc from the abstract, different boilerplate and your editorial comments. This may take a little bit (I’m not the only author).

Cheers,
Michael