![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Rick, > I hate to add a "me too" but I must. I believe that the RAB minutes would > be very useful if they were published. Has any other organization interested in publishing an informational RFC needed to also publish the internal discussions that led to the implementation of their proprietary protocol? > I am glad that NSI has published the I-D for their protocol, now does it > need to go beyond that and become an RFC, IMHO, no. I-Ds expire. > The IETF does not need to publish broken implementations of one companies > view of the shared gTLD registration process. Then you were unhappy that (oh, say) Cisco submitted RFC 2281 as an informational RFC (not saying HSRP is "broken", but I'm sure someone would). > Having an AD that sat on the > RAB promote the I-D and offer no reasoning as to why it > *should be* published as an Informational RFC reminds me of the bad taste > left by the IAHC and all the processes related. I find this offensive. I was among those who encouraged NSI to publish the RRP as an informational RFC as I felt it would be in the best interests of everybody to have the RRP protocol publically examined and I feel NSI should be commended for documenting their protocol. However, INFORMATIONAL RFCS DO NOT IMPLY ENDORSEMENT. The draft is a representation of an existing, in use proprietary protocol. No further justification should be necessary for documenting it as an informational RFC. Rgds, -drc
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.