Re: [Lsr] When is an IANA Registry Required

[Loa Andersson]

Toni, Ajun, et.al.,

I think that what Ajun says is that a IANA registry is often (very) 
practical long before it is "required".


I'm a bit concerned that by stating  a requirement, we might in practice 
raise the bar for then a registry is created. People read the 
requirement and says that ""Nay, it is not really need, so I won't 
create a new registry", and then a few years down the line we find that 
a registry would have been helpful.


So I'd say that as soon as you see that there might be more code points 
registered from the namespace you are creating, create a registry.


/Loa

On 23/03/2021 10:18, Aijun Wang wrote:

Hi, Les:

Even for IS-IS, there is already the flag registries example, please see 
the following pointer:


https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags 



And, even for your proposal 2), it is still not concise as the flag 
registries. Considering that we have one flag filed that has 16bit, and 
there will be 16 updates to the original document if it defines no bit 
at the beginning and every additional document defines one bit only?


Best Regards

Aijun Wang

China Telecom

*From:*lsr-boun...@ietf.org  *On Behalf Of *Les 
Ginsberg (ginsberg)

*Sent:* Monday, March 22, 2021 2:37 PM
*To:* Tony Li 
*Cc:* Christian Hopps ; Alvaro Retana 
; lsr-cha...@ietf.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; John Scudder 
; lsr@ietf.org

*Subject:* Re: [Lsr] When is an IANA Registry Required

Tony –

I hope I can be forgiven for one more post on this subject. In any case, 
here it is.


First, at the risk of some repetition, I want to emphasize that the 
reason I started this thread was to define a consistent policy. 
Currently we do not have registries for the flags fields in various 
TLVs. In recent document reviews, Alvaro strongly suggested that we 
introduce a registry for the flag field in the new TLV(s) which were 
being defined. I do not think the policy should be inconsistent in this 
regard, so I started this thread to get the WG to agree on what the 
policy will be across all such fields in all TLVs. Whatever the outcome 
of this discussion (i.e., to have such registries or to NOT have them), 
so long as there is a consistent policy, this thread will have served 
the purpose and I will be satisfied. (For those of you who may be fans 
of Ralph Waldo Emerson, I consider this to be NOT a “foolish 
consistency”. )


Now, as regards the potential usefulness of such registries, I think 
this has nothing to do with “memory”.  I can assure you that I refer to 
the existing registries with great frequency and do not trust my memory 
on such things.


Registries exist today (and are very useful) for number spaces for which 
requests come from a large number of largely unrelated documents. So, 
for top level TLVs, almost every IS-IS related RFC which has been 
published defines one or more codepoints. Without a registry our ability 
to track what is currently allocated and what is available would be 
severely compromised. Similarly for sub-TLVs and the other registries 
under the TLV Codepoints umbrella. However, in regards to flags fields 
which are part of the fixed portion of a TLV format definition, tracking 
bit allocation has not been an issue – and I argue that it is best 
tracked in other ways which are already defined. To be specific:


If an additional flag bit for an existing  TLV is defined in the future, 
there are two possible ways of doing this:


1)A bis document is written. The new document then contains all 
normative content from the original document as well as the new content 
(in this example an additional flag bit). The new document is required 
to be marked as “obsoleting” the original version. Once the document is 
published, the original document is marked as “obsoleted by xxx” and the 
existing entry for the affected code point in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
 
is marked to point to the new document.


2)A separate document is written focused only on the additions to the 
base definition for the TLV. The new document is required to be clearly 
marked as “updating” the original document. The original document is 
marked as “updated by new document”. In addition, the existing entry in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
 
would be updated to point to both the original document and the new 
document.


This seems to me be fully functional and easy to use. Even if your 
memory on such matters is not fresh, by simply bookmarking 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 

Re: [Lsr] When is an IANA Registry Required

[Aijun Wang]

Hi, Les:

Even for IS-IS, there is already the flag registries example, please see the 
following pointer:

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags

 

And, even for your proposal 2), it is still not concise as the flag registries. 
Considering that we have one flag filed that has 16bit, and there will be 16 
updates to the original document if it defines no bit at the beginning and 
every additional document defines one bit only?

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Monday, March 22, 2021 2:37 PM
To: Tony Li 
Cc: Christian Hopps ; Alvaro Retana 
; lsr-cha...@ietf.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; John Scudder ; 
lsr@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required

 

Tony –

 

I hope I can be forgiven for one more post on this subject. In any case, here 
it is.

 

First, at the risk of some repetition, I want to emphasize that the reason I 
started this thread was to define a consistent policy. Currently we do not have 
registries for the flags fields in various TLVs. In recent document reviews, 
Alvaro strongly suggested that we introduce a registry for the flag field in 
the new TLV(s) which were being defined. I do not think the policy should be 
inconsistent in this regard, so I started this thread to get the WG to agree on 
what the policy will be across all such fields in all TLVs. Whatever the 
outcome of this discussion (i.e., to have such registries or to NOT have them), 
so long as there is a consistent policy, this thread will have served the 
purpose and I will be satisfied. (For those of you who may be fans of Ralph 
Waldo Emerson, I consider this to be NOT a “foolish consistency”.  )

 

Now, as regards the potential usefulness of such registries, I think this has 
nothing to do with “memory”.  I can assure you that I refer to the existing 
registries with great frequency and do not trust my memory on such things.

 

Registries exist today (and are very useful) for number spaces for which 
requests come from a large number of largely unrelated documents. So, for top 
level TLVs, almost every IS-IS related RFC which has been published defines one 
or more codepoints. Without a registry our ability to track what is currently 
allocated and what is available would be severely compromised. Similarly for 
sub-TLVs and the other registries under the TLV Codepoints umbrella. However, 
in regards to flags fields which are part of the fixed portion of a TLV format 
definition, tracking bit allocation has not been an issue – and I argue that it 
is best tracked in other ways which are already defined. To be specific:

 

If an additional flag bit for an existing  TLV is defined in the future, there 
are two possible ways of doing this:

 

1)A bis document is written. The new document then contains all normative 
content from the original document as well as the new content (in this example 
an additional flag bit). The new document is required to be marked as 
“obsoleting” the original version. Once the document is published, the original 
document is marked as “obsoleted by xxx” and the existing entry for the 
affected code point in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
is marked to point to the new document. 

 

2)A separate document is written focused only on the additions to the base 
definition for the TLV. The new document is required to be clearly marked as 
“updating” the original document. The original document is marked as “updated 
by new document”. In addition, the existing entry in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
would be updated to point to both the original document and the new document.

 

This seems to me be fully functional and easy to use. Even if your memory on 
such matters is not fresh, by simply bookmarking 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
you will easily be able to find whatever information you need.

 

The addition of a separate registry for each flags field is then redundant at 
best. And redundancy in such matters introduces additional work and the 
possibility of unintentional inconsistency which I find hard to justify. Hence 
my conclusion that the value of such additional registries does not justify 
their creation.

 

You (and others) may still disagree. And I assure you that as my primary 
motivation for this thread was to have a consistent WG policy for such fields, 
I will abide by whatever policy is chosen by the WG even if it is not my 
preferred choice. But I do think the arguments being made for the creation of 
such registries bear closer scrutiny. Just my opinion of course…

 

Thanx (again) for listening.

 

   Les

 

 

From: Tony Li mailto:tony1ath...@gmail.com> > On Behalf 
Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les 

Re: [Lsr] Split was Re: Draft minutes for BFD @ IETF110

[Yingzhen Qu]

Hi,

I also support the split of ietf-bfd-mpls-te module from the base BFD module, 
so modules like ietf-ospf and ietf-isis can progress.

Thanks,
Yingzhen

> On Mar 22, 2021, at 2:33 AM, tom petch  wrote:
> 
> 
> 
> From: Rtg-bfd  on behalf of Reshad Rahman 
> 
> Sent: 19 March 2021 18:58
> To: rtg-bfd@ietf. org
> Subject: Draft minutes for BFD @ IETF110
> 
> BFD WG,
> 
> Draft minutes have been posted @ 
> https://datatracker.ietf.org/doc/minutes-110-bfd/
> 
> Please provide comments to the list by April 2nd.
> 
> 
> I support Acee's suggestion that the TE part should be split from the BFD 
> YANG draft so that the other three WG, who have been held up for years, can 
> progress.
> 
> Tom Petch
> 
> Copying the LSR WG.
> 
> 
> Meeting recording is @ https://www.youtube.com/watch?v=vSqfJJ3gOc0
> 
> Regards,
> Reshad.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

[Lsr] Split was Re: Draft minutes for BFD @ IETF110

[tom petch]

From: Rtg-bfd  on behalf of Reshad Rahman 

Sent: 19 March 2021 18:58
To: rtg-bfd@ietf. org
Subject: Draft minutes for BFD @ IETF110

BFD WG,

Draft minutes have been posted @ 
https://datatracker.ietf.org/doc/minutes-110-bfd/

Please provide comments to the list by April 2nd.


I support Acee's suggestion that the TE part should be split from the BFD YANG 
draft so that the other three WG, who have been held up for years, can progress.

Tom Petch

Copying the LSR WG.


Meeting recording is @ https://www.youtube.com/watch?v=vSqfJJ3gOc0

Regards,
Reshad.

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

Re: [Lsr] When is an IANA Registry Required

[Christian Hopps]

> On Mar 22, 2021, at 2:37 AM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Tony –
> 
> I hope I can be forgiven for one more post on this subject. In any case, here 
> it is.
> 
> First, at the risk of some repetition, I want to emphasize that the reason I 
> started this thread was to define a consistent policy. Currently we do not 
> have registries for the flags fields in various TLVs. In recent document 
> reviews, Alvaro strongly suggested that we introduce a registry for the flag 
> field in the new TLV(s) which were being defined. I do not think the policy 
> should be inconsistent in this regard, so I started this thread to get the WG 
> to agree on what the policy will be across all such fields in all TLVs. 
> Whatever the outcome of this discussion (i.e., to have such registries or to 
> NOT have them), so long as there is a consistent policy, this thread will 
> have served the purpose and I will be satisfied. (For those of you who may be 
> fans of Ralph Waldo Emerson, I consider this to be NOT a “foolish 
> consistency”.  )
> 
> Now, as regards the potential usefulness of such registries, I think this has 
> nothing to do with “memory”.  I can assure you that I refer to the existing 
> registries with great frequency and do not trust my memory on such things.
> 
> Registries exist today (and are very useful) for number spaces for which 
> requests come from a large number of largely unrelated documents. So, for top 
> level TLVs, almost every IS-IS related RFC which has been published defines 
> one or more codepoints. Without a registry our ability to track what is 
> currently allocated and what is available would be severely compromised. 
> Similarly for sub-TLVs and the other registries under the TLV Codepoints 
> umbrella. However, in regards to flags fields which are part of the fixed 
> portion of a TLV format definition, tracking bit allocation has not been an 
> issue – and I argue that it is best tracked in other ways which are already 
> defined. To be specific:
> 
> If an additional flag bit for an existing  TLV is defined in the future, 
> there are two possible ways of doing this:
> 
> 1)A bis document is written. The new document then contains all normative 
> content from the original document as well as the new content (in this 
> example an additional flag bit). The new document is required to be marked as 
> “obsoleting” the original version. Once the document is published, the 
> original document is marked as “obsoleted by xxx” and the existing entry for 
> the affected code point in 
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
>  
> 
>  is marked to point to the new document.
> 
> 2)A separate document is written focused only on the additions to the base 
> definition for the TLV. The new document is required to be clearly marked as 
> “updating” the original document. The original document is marked as “updated 
> by new document”. In addition, the existing entry in 
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
>  
> 
>  would be updated to point to both the original document and the new document.

As WG member,

I have approached this generally in the following way. If the flags field seems 
to be of the type (1) no IANA registry should be required. If the flags field 
seems to be of the type (2) then one could allocate a registry or leave it to 
the updating document to do so. The more one expects that a type (2) document 
is likely to be written, the more one should really consider creating the 
registry up-front in the field defining document.

IOW I don't think one should have to follow a tree of "updates" links hunting 
down *possible* new flag definitions, but following an "obsoleted by" chain to 
the latest version of a document is expected, and in this case the registry 
content would always point at a single document so would not be of any real 
value.

Thanks,
Chris.

> This seems to me be fully functional and easy to use. Even if your memory on 
> such matters is not fresh, by simply bookmarking 
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
>  
> 
>  you will easily be able to find whatever information you need.
> 
> The addition of a separate registry for each flags field is then redundant at 
> best. And redundancy in such matters introduces additional work and the 
> possibility of unintentional inconsistency which I find hard to justify. 
> Hence my conclusion that the value of such additional registries does not 
> justify their creation.
> 
> You (and others) may still disagree. And I assure you that as my primary 
> motivation for this thread was to have a consistent WG policy for such 
> fields, I will abide 

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

[Ketan Talaulikar (ketant)]

Hi Watson,

Thanks for your review.

-Ketan

-Original Message-
From: Watson Ladd via Datatracker  
Sent: 20 March 2021 11:03
To: sec...@ietf.org
Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; last-c...@ietf.org; 
lsr@ietf.org; watsonbl...@gmail.com
Subject: Secdir last call review of draft-ietf-lsr-ospf-prefix-originator-09

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] When is an IANA Registry Required

[Les Ginsberg (ginsberg)]

Tony –

I hope I can be forgiven for one more post on this subject. In any case, here 
it is.

First, at the risk of some repetition, I want to emphasize that the reason I 
started this thread was to define a consistent policy. Currently we do not have 
registries for the flags fields in various TLVs. In recent document reviews, 
Alvaro strongly suggested that we introduce a registry for the flag field in 
the new TLV(s) which were being defined. I do not think the policy should be 
inconsistent in this regard, so I started this thread to get the WG to agree on 
what the policy will be across all such fields in all TLVs. Whatever the 
outcome of this discussion (i.e., to have such registries or to NOT have them), 
so long as there is a consistent policy, this thread will have served the 
purpose and I will be satisfied. (For those of you who may be fans of Ralph 
Waldo Emerson, I consider this to be NOT a “foolish consistency”.  )

Now, as regards the potential usefulness of such registries, I think this has 
nothing to do with “memory”.  I can assure you that I refer to the existing 
registries with great frequency and do not trust my memory on such things.

Registries exist today (and are very useful) for number spaces for which 
requests come from a large number of largely unrelated documents. So, for top 
level TLVs, almost every IS-IS related RFC which has been published defines one 
or more codepoints. Without a registry our ability to track what is currently 
allocated and what is available would be severely compromised. Similarly for 
sub-TLVs and the other registries under the TLV Codepoints umbrella. However, 
in regards to flags fields which are part of the fixed portion of a TLV format 
definition, tracking bit allocation has not been an issue – and I argue that it 
is best tracked in other ways which are already defined. To be specific:

If an additional flag bit for an existing  TLV is defined in the future, there 
are two possible ways of doing this:

1)A bis document is written. The new document then contains all normative 
content from the original document as well as the new content (in this example 
an additional flag bit). The new document is required to be marked as 
“obsoleting” the original version. Once the document is published, the original 
document is marked as “obsoleted by xxx” and the existing entry for the 
affected code point in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
is marked to point to the new document.

2)A separate document is written focused only on the additions to the base 
definition for the TLV. The new document is required to be clearly marked as 
“updating” the original document. The original document is marked as “updated 
by new document”. In addition, the existing entry in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
would be updated to point to both the original document and the new document.

This seems to me be fully functional and easy to use. Even if your memory on 
such matters is not fresh, by simply bookmarking 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
you will easily be able to find whatever information you need.

The addition of a separate registry for each flags field is then redundant at 
best. And redundancy in such matters introduces additional work and the 
possibility of unintentional inconsistency which I find hard to justify. Hence 
my conclusion that the value of such additional registries does not justify 
their creation.

You (and others) may still disagree. And I assure you that as my primary 
motivation for this thread was to have a consistent WG policy for such fields, 
I will abide by whatever policy is chosen by the WG even if it is not my 
preferred choice. But I do think the arguments being made for the creation of 
such registries bear closer scrutiny. Just my opinion of course…

Thanx (again) for listening.

   Les


From: Tony Li  On Behalf Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg) 
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


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


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