Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

2020-08-19 Thread tom petch 

At the end

From: Les Ginsberg (ginsberg) 
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.


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 
> Sent: Wednesday, August 19, 2020 1:54 AM
>
> From: Rtg-bfd  on behalf of Les Ginsberg
> (ginsberg) 
> 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.
>
> 
> 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 
> Sent: Tuesday, August 18, 2020 8:09 PM
> To: Reshad Rahman (rrahman) 
> Cc: Robert Raszuk ; Les Ginsberg (ginsberg)
> ; Martin Vigoureux ;
> rtg-bfd@ietf.org
> 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)
> mailto:rrah...@cisco.com>> 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 : YANG for  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
>

RE: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

2020-08-19 Thread Les Ginsberg (ginsberg) 
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.

??

   Les


> -Original Message-
> From: tom petch 
> Sent: Wednesday, August 19, 2020 1:54 AM
> To: Les Ginsberg (ginsberg) ; Jeff Tantsura
> ; Reshad Rahman (rrahman)
> 
> Cc: rtg-bfd@ietf.org
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
> 
> From: Rtg-bfd  on behalf of Les Ginsberg
> (ginsberg) 
> 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.
> 
> 
> 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 
> Sent: Tuesday, August 18, 2020 8:09 PM
> To: Reshad Rahman (rrahman) 
> Cc: Robert Raszuk ; Les Ginsberg (ginsberg)
> ; Martin Vigoureux ;
> rtg-bfd@ietf.org
> 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)
> mailto:rrah...@cisco.com>> 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 : YANG for  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
> mailto:jefftant.i...@gmail.com>>
> Date: Tuesday, August 18, 2020 at 9:01 PM
> To: Robert Raszuk mailto:rob...@raszuk.net>>, "Les
> Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>,
> "Reshad Rahman (rrahman)"
> mailto:rrah...@cisco.com>>, Martin Vigoureux
> mailto:martin.vigour...@nokia.com>>
> Cc: "rtg-bfd@ietf.org"  b...@ietf.org>
> 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)
> mailto:rrahman=40cisco.com@dmar
> c.ietf.org>>, wrote:
> 
> 
> Indeed, draft-chen-bfd-unsolicited was informational

Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

2020-08-19 Thread tom petch 
From: Rtg-bfd  on behalf of Les Ginsberg (ginsberg) 

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.


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 
Sent: Tuesday, August 18, 2020 8:09 PM
To: Reshad Rahman (rrahman) 
Cc: Robert Raszuk ; Les Ginsberg (ginsberg) 
; Martin Vigoureux ; 
rtg-bfd@ietf.org
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) 
mailto:rrah...@cisco.com>> 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 
: YANG for  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 mailto:jefftant.i...@gmail.com>>
Date: Tuesday, August 18, 2020 at 9:01 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>, "Les Ginsberg 
(ginsberg)" mailto:ginsb...@cisco.com>>, "Reshad Rahman 
(rrahman)" mailto:rrah...@cisco.com>>, Martin Vigoureux 
mailto:martin.vigour...@nokia.com>>
Cc: "rtg-bfd@ietf.org" 
mailto:rtg-bfd@ietf.org>>
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) 
mailto:rrahman=40cisco@dmarc.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 mailto:rtg-bfd-boun...@ietf.org>> on 
behalf of Robert Raszuk mailto:rob...@raszuk.net>>
Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Cc: "rtg-bfd@ietf.org" 
mailto:rtg-bfd@ietf.org>>
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) 
mailto:40cisco@dmarc.ietf.org>> 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 mailto:rtg-bfd-boun...@ietf.org>> On 
> Behalf Of Jeffrey Haas
> Sent: Monday, August 17, 2020 1:45 PM
> To: rtg-...@ietf..org
> 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