![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
"David R. Conrad" wrote: > NSI should be treated no differently than others who publish proprietary > protocols as an informational RFC. Conrad: Of course. The IETF process is IMO actually a way of providing for controlled release of private information into public knowledge and use -- thus, a good thing. However, I regret that this whole DNS area is so politicized and polarized that instead of simply saying "I know this from the review work with NSI" even an IETF AD such as Patrik has to say round-about things like "If I remember correctly from a presentation NSI have had for me" and others like you feel compelled to say that NSI "should be commended for documenting their protocol." Gosh, if this is really a 'call' and the IETF really wants the opinion of those that help "make the Internet" ... and suffer with it, then can we please stay on the technical aspects? The technical aspect here is that the RRP protocol documented in the RFC proposed by NSI to the IETF is *not* what is being used by NSI and is also *not* what should be used. Thus, my viewpoint is that this is a "show stopper" in regard to the very purposes of informational RFCs (pls insert copy and paste from IETF charter) and the IETF should thus send NSI back to the drawing board. IETF RFCs, even informational and even not more than a bag of bytes in a server, should not be bureaucratic milestones in a chart but real contributions -- where it is OK to be wrong since in Science a NO is also an answer. But, an RFC should not be fictional or clearly wrong. Regarding your personal comment -- You might want to acquaint yourself with the process before declaring it "wrong" -- I take it as a compliment, because the only reason why I decided to say something here (after a week-old message to Scott when he did release the proposed RFC) is exactly because I am acquainted with the process but not as comfortable with it as you seem to be. Cheers, Ed Gerck
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.