Bir Belirtimin Standartlaşma Aşamaları
Önceki Genel Ağ Standartlarının Standartlaşma Süreci -- 3. Düzeltme Sonraki
Bir Belirtimin Standartlaşma Aşamaları
Genel Ağ Standardı olacağı düşünülen belirtimler "standartlaşma aşamaları" olarak bilinen bazı olgunluk seviyelerinden geçerler. Bu olgunluk seviyeleri -- "Standart Aday Adayı" (Proposed Standard), "Standart Adayı" (Draft Standard) ve "Standart" -- Standartlaşma Aşamalarının Olgunluk Seviyeleri bölümünde tanımlanmış ve açıklanmıştır. Belirtimlerin standartlaşma aşamalarından geçiş yöntemleri ise Genel Ağ Standartları Süreci bölümünde açıklanmıştır.
Bir belirtim bir Genel Ağ Standardı olarak kabul edildikten sonra bile, yeni gereksinimlerin ortaya çıkışına ve kazanılan deneyime bağlı olarak çoğunlukla gelişimini sürdürür. Genel Ağ Standartlaşımının yöntemleri ve terminolojisi eski Genel Ağ Standartlarının yenileriyle değiştirilmesi ve "tedavülden kaldırılan" Genel Ağ Standartlarının durumunu belirtecek tanımlayıcı etiketlerin atanması ile ilgili tüm gereksinimleri sağlar. Standartlaşma aşamalarına dahil edilmemiş olanlarını da kapsayarak bu belirtimlerin olgunluk seviyeleri Standartdışı Aşamaların Olgunluk Seviyeleri bölümünde tanımlanmıştır.
Standartlaşma Aşamalarının Olgunluk Seviyeleri
Genel Ağ Belirtimleri gelişim aşamalarından geçtikten sonra denenip kabul edilir. Genel Ağ Standartları Sürecinde bu aşamalar şekilsel olarak "olgunluk seviyeleri" diye adlandırılır.
Bu bölümde olgunluk seviyeleri ve belirtimlerin bu seviyelerdeyken kendilerinden beklenen karakteristikler açıklanmıştır.
Standart Aday Adayı
(Proposed Standard)
Standartlaşma aşamalarının giriş olgunluk seviyesi "Standart Aday Adayı" (Proposed Standard) olmaktır. Bir belirtimi "Standart Aday Adayı" seviyesinde bir belirtim olarak standartlaşma aşamalarına taşımak için IESG tarafından özel bir eylem gerekir.
Bir Standart Aday Adayı belirtim genelde kararlı, bilinen tasarım seçimleri tamamlanmış, iyi anlaşılır olduğuna inanılan, önemli bir toplumsal gözden geçirmeye uğramış, yeterli toplum yararına sahip olacakmış gibi görünen bir belirtimdir. Bununla birlikte böyle bir macera bir değişiklikle sonuçlanabilir veya terfi edeceğine belirtim geri bile çekilebilir.
Aslında, bir belirtimin Standart Aday Adayı olması için ne gerçeklenim ne de işlemsel deneyim gereklidir. Yine de, böyle bir deneyim daima istenir ve bu, Standart Aday Adayı olma lehine önemli bir argüman olacaktır.
Çekirdek Genel Ağ protokollerini esaslı olarak etkileyen veya Genel Ağ'da önemli bir işlemsel etki oluşturabilme davranışı belirten bir belirtime Standart Aday Adayı durumu vermeden önce IESG gerçeklenim ve/veya işlemsel deneyimi gerekli görebilir.
Bir Standart Aday Adayı belirtimin belirttiği gereksinimlerle ilgili olarak bilinen bir teknik kusuru olmamalıdır. Yine de, belirtimin gerekli (ve tam zamanında) ve kullanışlı olacağı gözönüne alındığında, bilinen bir teknik kusuru olsa bile IESG belirtimin Standart Aday Adaylığına getirilmesini mümkün kılmak için bu gereksinimi erteleyebilir.
Gerçekleyiciler Standart Aday Adayı bir belirtimi olgunlaşmamış bir belirtim olarak ele almalıdır. Deneyim kazanmak, değerlendirmek, denemek ve belirtimi arıtmak için gerçeklemek istenebilir. Yine de, Standart Aday Adayı bir belirtimin içeriği sorunlarla karşılaşılırsa ya da daha iyi çözümler bulunursa değişebileceğinden, bozulmaya duyarlı ortamlarda böyle standartların gerçekleniminin önünün açılması önerilmez.
Standart Adayı
(Draft Standard)
Farklı kod temelinde geliştirilmiş en azından iki bağımsız ve birlikte çalışabilir gerçeklenimi olan ve üzerinde yeterince başarılı işlemsel deneyim sağlanmış bir belirtim "Standart Adayı" (Draft Standard) seviyesine yükseltilebilir. Bu bölümün amacına uygun olarak "birlikte çalışabilir" olmakla kullanıldıkları süreç veya sistemin elemanlarının birbirleri yerine kullanılabilir olmaları veya işlevsel olarak eşdeğer olmaları kastedilmektedir. Gerçeklenim için sahipli olsun olmasın denetlenen bir teknoloji gerekliyse ayrı ayrı gerçeklenimler olmalı ve ayrıca bunlar lisanslama sürecinin ayrı ayrı kullanımlarından sonuçlanmış olmalıdır. Standart Adaylığına yükselmek, belirtimin olgunluğu ve yararlı olacağı konusunda kesin kanaat belirten, esaslı bir durum değişikliğidir.
En azından iki bağımsız ve birlikte çalışabilir gerçeklenim gereksinimi belirtimin tüm özelliklerine ve seçeneklerine uygulanır. Bazı özelliklerin ve seçeneklerin en azından iki birlikte çalışabilir gerçeklenimde gözlemlenemeyişi durumunda belirtim, Standart Adayı seviyesine bu özellik veya seçenekler kaldırılırsa yükseltilebilir.
Bu gerçeklenimlerin birlikte çalışabilirliğinin denenmesi hakkındaki belgeleme ile beraber Genel Ağ Standardı veya Adayı durumu için belirtimi nitelikli yapan gerçeklenimlerin belgelendirilmesinden Çalışma Grubu başkanlığı sorumludur. Belgeler her ayrı özellik ve seçeneğin her birinin nasıl desteklendiği hakkında bilgi içermelidir. Bu belgeler Alan Yöneticisine protokol eylem isteği ile teslim edilmelidir (Genel Ağ Standartları Süreci bölümüne bakınız).
Bir Standart Adayı gerek anlambilim gerekse bir gerçeklenim geliştirme temelinde kararlı olduğu bilinen ve iyi anlaşılan bir belirtim olmalıdır. Üretim ortamında çok geniş kapsamlı kullanıma konu olduğunda Standart Adayı belirtimin gerçeklenimlerinde beklenmedik davranışların gözlemlenmesi mümkün olduğundan Standart Adayının hala ilave olarak veya daha kapsamlı alanlarda denenmesi gerekebilir.
Bir Standart Adayı normalde gelişimini tamamlamış, değişiklik olacaksa bunların sadece saptanmış bellibaşlı sorunları çözümlemek için yapılacağı bir belirtim sayılır. Çoğu durumda, bozulmaya duyarlı ortamlarda Standart Adaylarının gerçeklenimlerinin önünün açılması üreticiler açısından uygundur.
Genel Ağ Standardı
Önemli gerçeklenimi olan ve başarıyla denenerek işlemsel deneyim kazanmış bir belirtim Genel Ağ Standardı seviyesine yükseltilebilir. Bir Genel Ağ Standardı (sadece Standart da denebilir) yüksek derecede teknik olgunluk ve belirtilen protokol veya hizmetin Genel Ağ toplumuna gerçekten önemli yararlar sağladığı şeklinde genel bir kanaat oluşturmuş olmakla karakterize edilir.
Standart durumuna gelen bir belirtime STD serisinden bir numara atanırken kendi RFC numarasına dokunulmaz.
Standartdışı Aşamaların Olgunluk Seviyeleri
Her belirtim standartlaşma aşamalarına girmez. Bir belirtim bir Genel Ağ Standardı olarak tasarlanmayabilir veya eninde sonunda standartlaşacağı düşünülmesine rağmen standartlaşma aşamalarına girmek için henüz hazır olmayabilir. Bir belirtim daha güncel bir Genel Ağ Standardı tarafından standartzede yapılmış olabilir veya bir şekilde gözden düşebilir ya da kullanımdışı kalabilir.
Standartlaşma aşamalarına sokulmayan belirtimler için aşamasız olarak üç olgunluk seviyesi vardır: "Deneysel" (Experimental), "Bilgilendirici" (Informational) ve "Tarihi" (Historic). Bu yaftaları taşıyan belgeler hiçbir manada Genel Ağ Standardı değildir.
Deneysel
"Deneysel" (Experimental) yaftası genellikle bir araştırma veya geliştirme çabasının parçası olan bir belirtimi ifade eder. Böyle bir belirtim standartlaşma süreci ile gereken koordinasyonun sağlanmış olduğunu doğrulamak (aşağıya bakınız) için ve sadece yayıncı değerlendirmelerine konu çalışmanın arşivsel kaydı olarak ve Genel Ağ teknik toplumunun genel bilgisi için yayınlanır. Bir Deneysel belirtim IRTF'nin bir Araştırma Grubu gibi örgütlü bir Genel Ağ araştırma çabasının sonucu olabileceği gibi bir IETF Çalışma Grubunun veya bağımsız bir katkıcının çabalarının bir sonucu da olabilir.
Bilgilendirici
Bir "Bilgilendirici" (Informational) belirtim Genel Ağ toplumunun bir fikir birliğini veya önerisini yansıtmayan ve Genel Ağ toplumunun genel bilgilenmesi için yayınlanmış bir belirtimdir. Bilgilendirici yaftası standartlaşma süreci ile gereken koordinasyonun sağlanmış olduğunu doğrulamak (Deneysel ve Bilgilendirici RFC'lerle ilgili İşlemler bölümüne bakınız) ve sadece yayıncı değerlendirmelerine konu çeşitli kaynaklardaki güvenilir bilgilendirici belgelerin çok kapsamlı bir aralıkta tam zamanında yayınlanmasını sağlamak için tasarlanmıştır.
Genel Ağ toplumunun dışında hazırlanmış ve Fikri Mülkiyet Hakları hükümlerine göre Genel Ağ Standartları Süreci ile bağdaşmayan belirtimler sahibinin izni ve RFC Editor'ün onayıyla Bilgilendirici Açıklama İsteği olarak yayınlanır.
Deneysel ve Bilgilendirici RFC'lerle ilgili İşlemler
IETF Çalışma Grubunun çalışmalarının sonucu olmaksızın, Deneysel veya Bilgilendirici durumla yayınlanması düşünülen belgeler doğrudan doğruya RFC Editor'e teslim edilmelidir. RFC Editor böyle bir belgeyi daha önce yaınlanmamışsa Genel Ağ Taslağı olarak yayınlayacaktır. Bunları diğer Genel Ağ Taslaklarından kolayca ayırdedebilmek için I-D dizininde gruplar. RFC Editor bunları işleme sokmadan önce yorumları alması için iki hafta bekletir. RFC Editor, bir belgenin Deneysel veya Bilgilendirici durumla yayınlanabilecek bir makale olabilirliği hakkında sağduyusunu kullanmak üzere üzerinde birilerinin çalışacağını umar. Belge Genel Ağ etkinlikleri ile ilgili değilse veya RFC'ler için teknik olsun olmasın bir standart olamıyorsa RFC Editor uzman takdirini kullanarak belgeyi yayınlamayı reddedebilir.
Standartdışı aşamalar olarak Deneysel ve Bilgilendirici yaftalarının Genel Ağ Standartları Sürecini bozmak amacıyla yanlış kullanıma konu edilmediğinden emin olmak için, IESG ve RFC Editor, IETF topluluğunca yapılmış ya da yapılacağı umulan bir çalışmayla ilgili olarak Deneysel veya Bilgilendirici yayın olmak üzere RFC Editor'ün takdirine bırakılmış her belgeyi RFC Editor'ün IESG'ye havale edeceğini kabul eder. IESG böyle bir belgeyi makul bir süre içinde gözden geçirecek ve, ya teslim edildiği özgün haliyle yayınlanmasını ya da Genel Ağ Standartları Sürecine bir katkı olarak IETF'ye havale edilmesini önerecektir.
Eğer
  1. IESG'nin IETF bağlamında işleme sokulmak üzere IETF'ye sevkettiği ama yazarının böyle olmasını reddettiği veya
  2. IESG'nin belgenin ileri sürdüğü şeylerin mevcut bir IETF çalışmasına aslında muhalif olduğunu veya çeliştiğini varsaydığı
bir belge yine de bir Deneysel veya Bilgilendirici Açıklama İsteği olarak yayınlanabilir. Bu durumlarda, yine de, belgenin hangi durumlarla yayınlandığına dair okuyucuya bilgi vermek üzere, belgenin hemen başındaki "Bu Belgenin Durumu" bölümüne veya belgenin uygun bir yerine IESG bir "feragatname" yerleştirebilir.
IETF Çalışma Gruplarınca Deneysel veya Bilgilendirici RFC'ler olması amaçlanan belgeler IESG gözden geçirmesine gider. Gözden geçirme işlemi Olayın Başlatılması bölümünde açıklanan süreç kullanılarık başlatılır.
Tarihi
Daha güncel bir belirtim tarafından standartzede yapılmış veya herhangi bir sebeple kullanımdışı olacağı varsayılan bir belirtime "Tarihî" (Historic) seviyesi atanır. (Lisan arıtıcılar bu amaçla kullanılacak terimin "Ezelî" ("Historic" değil "Historical") olması gerektiğini söylerler; yine de "Tarihi" sözcüğü bu noktada "ezelî" anlamında kullanılmıştır[150]).
Not
Standart aşamalarındaki belirtimlerin, (başka standart kurullarından sevkedilmiş belirtimlerden olmayıp) standartdışı aşamalardaki belirtimlerle veya başka (başka burada "harici/dış" anlamında sanırım) standart aşamalarının olgunluk seviyelerinden daha düşüğündeki belirtimlerle ilgili olmaması gerekir. (Harici Standartlar ve Belirtimler bölümüne bakınız.)


[150] Ç.N.: "Historical" sözcüğünün tarihe malolmuş ama efsane olmayan (eskiden gerçekleştiği bilinen) ancak bir tarih de düşülmemiş durumları kastettiğinden hareketle dilimize "Ezelî" olarak çevirmeyi anlatılmak isteneni daha iyi betimlediğinden daha uygun gördüm. Ama belgenin yazarının yaptığı gibi yapıp ben de uygun olmayan terimi kullandım.
Önceki Üst Ana Başlık Sonraki
Genel Ağ Standardı Belirtimleri Başlangıç Şu anki En İyi Uygulama (BCP) RFC'leri
Bir Linux Kitaplığı Sayfası