RE: Last Call <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ross,

See inline.

> This is not actually correct. The IETF has a very long history of
> pushing back on multiple redundant solutions to the same problem. There
> are a great many cases of ADs, working group chairs, and others pushing
> quite hard to prevent multiple solutions when one would work fine.

I didn't mean to say that the IETF in general allows multiple solutions but I think it is accurate to say that the IETF has a less than 100% success rate of preventing multiple solutions.

> In the very many previous cases it was not necessary to write a
> document because the second (or third, or ...) solution was within the
> same standards body, and it was possible to either prevent publication,
> or publish the second solution as informational, or publish the second
> solution with a disclaimer up front saying some form of "we recommend
> this other solution [add normative reference] which is the agreed IETF
> standard".

You are making a point on which I picked earlier because it is stated in the document as well. In case there are multiple solutions, documenting, but at the same time discouraging the other one has happened before. Why is this not possible in this case? Make one the default, the other optional with a big red warning sign.

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]