Hi Reshad, all, I don't think that there is any hard and fast rule that just because a document contains YANG it must be stds track. E.g., a vendor could publish their proprietary protocol as informational and a YANG management model alongside, also as informational.
But in this particular case, I see that the YANG model is really defining a standard management API for a BFD feature and as such I think that the doc containing the YANG model should be stds track. However, regardless of the YANG, I think that I would regard the rest of the doc as Stds track as well anyway but would defer to the RTG ADs on this point. Hence, my suggestion would be to just publish it as a single stds track doc. Regards, Rob > -----Original Message----- > From: Reshad Rahman (rrahman) <[email protected]> > Sent: 30 October 2020 15:56 > To: tom petch <[email protected]>; Les Ginsberg (ginsberg) > <[email protected]>; Jeff Tantsura <[email protected]>; Rob Wilton > (rwilton) <[email protected]>; Warren Kumari <[email protected]> > Cc: [email protected]; Jeffrey Haas <[email protected]>; > [email protected] > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited > (ending 16 August, 2020) > > Jeff, Martin, Rob, Warren, > > Any guidance on this? As mentioned below, I favour having the YANG model > in the same document. If we go that way, the question then is whether the > document is informational or not. > > Regards, > Reshad (no hat). > > On 2020-08-19, 11:04 AM, "tom petch" <[email protected]> wrote: > > <tp> > At the end > > From: Les Ginsberg (ginsberg) <[email protected]> > Sent: 19 August 2020 15:42 > > Tom - > > I defer to chairs/AD in this matter - but here is my understanding of > the distinction between Normative and Informative References. > From https://www.rfc-editor.org/policy.html#policy.refs > > " Within an RFC, references to other documents fall into two general > categories: "normative" and "informative". Normative references specify > documents that must be read to understand or implement the technology in > the new RFC, or whose technology must be present for the technology in the > new RFC to work. An informative reference is not normative; rather, it > only provides additional information. For example, an informative > reference might provide background or historical information. Informative > references are not required to implement the technology in the RFC." > > To me what this means is that it is the role of the referenced > document in the document in which the reference appears which determines > its category - not whether the referenced document itself is Informational > or Standard. > So an Informational RFC could be necessary to understand a standards > track document - in which case it SHOULD be a Normative Reference. > Similarly, a Standards RFC could be merely informational in its role > as a reference and therefore be an Informative Reference. > > Of course what Jeff and I are suggesting is that there be one document > which includes both YANG and the descriptive text of the functionality and > that this be Informational. > The more relevant question seems to be whether it is a violation of > IETF Policy to have YANG defined in an Informational RFC. > > <tp> > I agree with your characterisation of Normative and Informative. > > With split documents, then it seems clear to me that there would be a > Normative Reference from the YANG document to the non-YANG one since it is > impossible to make sense of the YANG one without understanding the use of > the BFD protocol. If the non-YANG one is Informational, then you have a > downref from one to the other which is more work for the AD and IESG which > I would seek to avoid. > > I went through YANG and YANG Guidelines and there is no explicit > statement that a Normative YANG module (which this one clearly is AFAICT) > must be in a Standards Track I-D but there are plenty of places where that > is implicit, the alternatives being e.g. the document of another SDO > versus IETF Standards track with no consideration of IETF not on the > Standards track so I think that a single Informational document is also > more work for the AD to push through the IESG. > > Which leaves a single Standards Track document as the best alternative > IMHO with text to allay the concerns expressed here about the absence of > changes to the protocol. > > I would see Ops AD as the authority on this , the one who has to > convince the IESG of the correctness of the WG decision, to make the > presence of a YANG module the deciding factor; I cannot recall it arising > before. YMMV > > Tom Petch > . > ?? > > Les > > > -----Original Message----- > > From: tom petch <[email protected]> > > Sent: Wednesday, August 19, 2020 1:54 AM > > > > From: Rtg-bfd <[email protected]> on behalf of Les Ginsberg > > (ginsberg) <[email protected]> > > Sent: 19 August 2020 06:44 > > > > I would prefer this as well – but if that violates some YANG process > in the > > IETF please do make sure the draft clearly states that there are no > protocol > > changes. > > > > <tp> > > The YANG will need a Normative Reference to the other document, > AFAICT, > > so making the other document Informative just introduces > complications to > > the process, > > > > Tom Petch > > > > > > > > > > > > Les > > > > > > From: Jeff Tantsura <[email protected]> > > Sent: Tuesday, August 18, 2020 8:09 PM > > To: Reshad Rahman (rrahman) <[email protected]> > > Cc: Robert Raszuk <[email protected]>; Les Ginsberg (ginsberg) > > <[email protected]>; Martin Vigoureux <[email protected]>; > > [email protected] > > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited > (ending 16 > > August, 2020) > > > > An informational document that also has a management/YANG part > included > > would IMHO be the right outcome. > > Regards, > > Jeff > > > > > > On Aug 18, 2020, at 19:38, Reshad Rahman (rrahman) > > <[email protected]<mailto:[email protected]>> wrote: > > > > Hi Jeff and Les, > > > > In general I prefer to have the 2 together (here’s the protocol > details and > > here’s how it’s managed), IMHO there’s benefit in having the 2 > together > > since the YANG discussions are happening while we’re in the thick of > the > > protocol discussions. I am actually not keen to end up with 2 docs, > RFC XXX > > and RFC YYYY: YANG for XXXX with 2 different lifecycles, by the time > the > > YANG is done people aren’t interested anymore because the protocol > spec is > > done. I brought this up some time ago with RTG AD and OPS AD, but I > don’t > > think there was any conclusion. > > > > In this specific case, I agree that there’s no protocol changes. So > with 2 > > documents, are you proposing that the BFD spec should be > informational and > > the YANG standards track? Or both informational? If it’s the latter, > I’d rather > > they be in the same doc. > > > > Regards, > > Reshad ( no hat). > > From: Jeff Tantsura > > <[email protected]<mailto:[email protected]>> > > Date: Tuesday, August 18, 2020 at 9:01 PM > > To: Robert Raszuk <[email protected]<mailto:[email protected]>>, > "Les > > Ginsberg (ginsberg)" > <[email protected]<mailto:[email protected]>>, > > "Reshad Rahman (rrahman)" > > <[email protected]<mailto:[email protected]>>, Martin Vigoureux > > <[email protected]<mailto:[email protected]>> > > Cc: "[email protected]<mailto:[email protected]>" <rtg- > > [email protected]<mailto:[email protected]>> > > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited > (ending 16 > > August, 2020) > > > > IMHO - It isn’t right that presence of YANG defines document’ > designation > > track. The common practice is that if the draft in question doesn’t > require any > > protocol changes it should aim for Informational track (or BCP). > > https://ietf.org/standards/process/informational-vs-experimental/ > > > > I’d rather have 2 separate documents. In general, given that YANG > > documents life cycle is quite different from that of protocol ones, > it is > > perhaps a good practice to keep them separate. > > I have included Martin (Routing AD for BFD) > > > > Cheers, > > Jeff > > On Aug 18, 2020, 4:24 AM -0700, Reshad Rahman (rrahman) > > <[email protected]<mailto:rrahman=40cisco.com@dmar > > c.ietf.org>>, wrote: > > > > > > Indeed, draft-chen-bfd-unsolicited was informational and with the > addition > > of the YANG module draft-ietf-bfd-unsolicted was changed to > standards > > track. > > > > Regards, > > Reshad (no hat). > > > > From: Rtg-bfd <[email protected]<mailto:rtg-bfd- > > [email protected]>> on behalf of Robert Raszuk > > <[email protected]<mailto:[email protected]>> > > Date: Tuesday, August 18, 2020 at 5:44 AM > > To: "Les Ginsberg (ginsberg)" > > > <[email protected]<mailto:ginsberg=40cisco.com@dmar > > c.ietf.org>> > > Cc: "[email protected]<mailto:[email protected]>" <rtg- > > [email protected]<mailto:[email protected]>> > > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited > (ending 16 > > August, 2020) > > > > Hi Les, > > > > While shifting to Informational would be perhaps ok protocol wise - > isn't it > > common practice in IETF that any draft (or at least most of them) > which > > define a YANG model is a Standards Track document ? > > > > I hope you are not suggesting to split this one into two :). > > > > Thx, > > R. > > > > On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) > > > <[email protected]<mailto:[email protected] > > >> wrote: > > Sorry to be tardy in responding... > > > > As I stated almost 2 years ago when this draft was introduced: > > > > a)The problem the draft is addressing is real and the solution > useful > > > > b)There are implementations which have already addressed this > problem > > with no interoperability issues > > > > c)I do not see that any changes have been made to the BFD protocol > (e.g.. > > RFC 5881) > > > > Therefore, I think this should go forward - but as Informational. > > > > Les > > > > > > > -----Original Message----- > > > From: Rtg-bfd <[email protected]<mailto:rtg-bfd- > > [email protected]>> On Behalf Of Jeffrey Haas > > > Sent: Monday, August 17, 2020 1:45 PM > > > To: [email protected]<mailto:[email protected]> > > > Subject: Re: Working Group Last Call for draft-ietf-bfd- > unsolicited (ending > > 16 > > > August, 2020) > > > > > > On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote: > > > > Working Group, > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/ > > > > > > > > With apologies to the authors of BFD unsolicited, this document > is past > > due > > > > for Working Group Last Call. The primary holdup on the document > had > > > been > > > > last minute interaction with the RFC Editor with regard to its > impact on > > the > > > > BFD Yang model. That work had completed some time ago.. (The > Yang > > > model, > > > > however, is still lingering in MISREF state.) > > > > > > > > This begins a last call period ending on 16 August. > > > > > > The last call period has ended with a few comments from Greg and > Raj that > > > should be addressed before we continue. > > > > > > It'd also be helpful to hear from additional reviewers before we > advance > > > this document. > > > > > > -- Jeff
