[Lsr] Secdir last call review of draft-ietf-lsr-ospf-prefix-originator-09

[Watson Ladd via Datatracker]

Reviewer: Watson Ladd
Review result: Ready

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The summary of the review is Ready.

This document describes a small extension to OSPF to include 
information of the originating router for a prefix, which otherwise
would be lost as the prefix proceeds to be readvertised. This information
is quite useful when determining what is going on under trying circumstances.

Sincerely,
Watson Ladd


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

[Ketan Talaulikar (ketant)]

Hi Alvaro,

Thanks for that confirmation and the updated draft version has been posted with 
the changes.

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-09

Thanks,
Ketan

-Original Message-
From: Alvaro Retana  
Sent: 16 March 2021 23:23
To: Ketan Talaulikar (ketant) ; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Cc: John Scudder ; lsr-cha...@ietf.org; lsr@ietf.org; 
Christian Hopps 
Subject: RE: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

 Ketan:

Hi!

I’m ok with your responses — I think we’re good to go.

Thanks!

Alvaro.


On March 9, 2021 at 12:42:21 PM, Ketan Talaulikar wrote:

> I will wait for your responses on a few of the points before posting 
> the draft update.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-originator-09.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : OSPF Prefix Originator Extensions
Authors : Aijun Wang
  Acee Lindem
  Jie Dong
  Peter Psenak
  Ketan Talaulikar
Filename: draft-ietf-lsr-ospf-prefix-originator-09.txt
Pages   : 10
Date: 2021-03-19

Abstract:
   This document defines OSPF extensions to include information
   associated with the node originating a prefix along with the prefix
   advertisement.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-09
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-prefix-originator-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] When is an IANA Registry Required

[bruno.decraene]

+1
The information needs to be tracked and consolidated. Seems better done by a 
single person than by many persons duplicating the work, not to mention by zero 
person (surely someone else is doing the job).
This may be less important in LSR though, as we have designated experts which 
may already do this work. However:
-IINM, the designated expert is only appointed when there is a registry.
-IMHO there would be value in having the tracking data been public. IANA looks 
good to me. In theory, github may also work.

That also assumes that code point/flags be tracked -hence allocated- soon 
enough, rather than been hidden in a draft or specific implementation.

Thanks,
--Bruno

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, March 18, 2021 6:15 PM
To: Les Ginsberg (ginsberg) ; Tony Li 
Cc: Alvaro Retana ; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; John Scudder 
; Christian Hopps ; lsr-cha...@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required

Speaking as WG member:

Hi Les,
My opinion is there is no harm and some advantage in having IANA registries for 
unique IGP protocol bit flag fields. For the existing fields that don’t have 
registries, there is no burning requirement to go back and define an IANA 
registry until such time as that flag field is extended.

Note that for OSPF, we did add these registries in 
https://www.rfc-editor.org/rfc/rfc4940.txt (thanks to Kireeti).
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Thursday, March 18, 2021 at 12:44 PM
To: Tony Li mailto:tony...@tony.li>>
Cc: Alvaro Retana mailto:aretana.i...@gmail.com>>, 
"draft-ietf-lsr-isis-srv6-extensi...@ietf.org"
 
mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>>,
 "lsr@ietf.org" mailto:lsr@ietf.org>>, John 
Scudder mailto:j...@juniper.net>>, Christian Hopps 
mailto:cho...@chopps.org>>, 
"lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] When is an IANA Registry Required
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Resent-Date: Thursday, March 18, 2021 at 12:44 PM

Tony –

In this context I don’t find the use of a registry of value. The primary issue 
for me for these fields is not managing the bit assignments but understanding 
the functionality – and for that I need to look at the document(s) which have 
that definition. A registry in these cases provides little value and adds 
process and a possibility for inconsistency.

But, I am not expecting that there is anything I can say to change your opinion 
– nor vice versa. So I appreciate that you have made your POV clear and the 
reasons for it – and I am not trying to change your opinion.

I started this thread because I did not think a change in WG policy should be 
made solely based on a single document review comment from one individual – 
even one as highly respected as Alvaro.
Thus far we have a handful of opinions – I am hoping more members of the WG 
will respond to the thread and then we can proceed appropriately.

   Les

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Alvaro Retana mailto:aretana.i...@gmail.com>>; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 lsr@ietf.org; John Scudder 
mailto:j...@juniper.net>>; Christian Hopps 
mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required


Les,



IMO, there is no need for registries for the first category. The WG has been 
alive for over 20 years, defined many new TLVs with flags fields, and I am not 
aware of any confusion – so if it ain’t broke don’t fix it.


With all due respect Les, you appear to operate with an eidetic memory of all 
things IS-IS, so I think that you discount the confusion that the rest of us 
live in.

If a field has values defined in two documents, then there’s confusion. Even 
just finding both is a challenge.

Regards,
Tony



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be