Subject: draft-ietf-bfd-intervals IANA considerations?

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 7 Apr 2014 17:07:00 +0000

Hi BFDers,

Authors of draft-ietf-bfd-intervals have discussed and concluded that defined "common intervals set" does _not_ need to be maintained by IANA.

Reasons:
1. Document is an informational draft.
2. Additions of interval(s) in the "common intervals set" should anyways be done through a new draft, whether or not draft-ietf-bfd-intervals creates an IANA registry and defines allocation policies for it.

Do you agree with this?
Do you see any concern with this?

Seeking opinions/comments from folks on this matter.

Thanks,
Nobo, Marc, Greg

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 7 Apr 2014 23:05:07 -0400

There is no problem with having IANA Considerations setting up a
registry or the like in an Informational document.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 8 Apr 2014 03:11:40 +0000

Donald,

I agree with this as a general statement. As it pertains to the ³Common
interval values², it does not appear that is the role of an IANA numbers
registry.

Thanks,

Carlos.

-----Original Message-----
From: Donald Eastlake <[email-masked]>
Date: Monday, April 7, 2014 at 11:05 PM
To: Nobo Akiya <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-bfd-intervals IANA considerations?

>> Authors of draft-ietf-bfd-intervals have discussed and concluded that
>>defined "common intervals set" does _not_ need to be maintained by IANA.
>>
>> Reasons:
>> 2. Additions of interval(s) in the "common intervals set" should
>>anyways be done through a new draft, whether or not
>>draft-ietf-bfd-intervals creates an IANA registry and defines allocation
>>policies for it.
>>
>> Do you agree with this?

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 8 Apr 2014 04:40:51 +0000

Carlos and all,
I am not sure I follow the logic of the decision.
Donald has already commented on setting a new registry in an Informational document; and saying that new values would be always set via a new draft seems to map well to one of the already existing IANA policies.

But what worries me most is the fact that without a IANA registry there will be no single place where these "common interval values" could be looked up by implementers. Instead, they would have to track a (potentially long) sequence of documents in order to understand what they should try to implement and test.

I could also say that operators commonly request "compliance" with Informational documents in RFPs and RFIs they publish. (Somebody has recently mentioned requests to comply with some April 1  RFCs as well on the RTG-DIR :-).And while such an argument would not hold in the court of law, I am not sure we should simply ignore it.

My 2c,
     Sasha

________________________________________
From: Rtg-bfd <[email-masked]> on behalf of Carlos Pignataro (cpignata) <[email-masked]>
Sent: Tuesday, April 8, 2014 6:11 AM
To: Donald Eastlake; Nobo Akiya (nobo)
Cc: [email-masked]
Subject: Re: draft-ietf-bfd-intervals IANA considerations?

Donald,

Thanks,

Carlos.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 8 Apr 2014 14:31:36 +0000

Hi Sasha, Carlos, Donald, all,

Thanks for comments.

Sasha, Donald, I think you are saying we can create IANA registry, which I agree. But are you saying we *should* create IANA registry for this document?

Comments inline.

> Donald has already commented on setting a new registry in an
> Informational document; and saying that new values would be always set
> via a new draft seems to map well to one of the already existing IANA
> policies.

Sure. My question then is, if we were to create one IANA registry for "common interval values", do we create one registry or also prepare *optional* registry where intervals specific to application/session-type can go into?

> But what worries me most is the fact that without a IANA registry there will
> be no single place where these "common interval values" could be looked
> up by implementers. Instead, they would have to track a (potentially long)
> sequence of documents in order to understand what they should try to
> implement and test.

We probably won't have that many "updates", and it shouldn't be that difficult to locate right documents via internet. If we see a trend of possible iterative updates, it's possible to create an IANA registry at that point as well (with first of such draft).

> I could also say that operators commonly request "compliance" with
> Informational documents in RFPs and RFIs they publish. (Somebody has
> recently mentioned requests to comply with some April 1  RFCs as well on
> the RTG-DIR :-).And while such an argument would not hold in the court of
> law, I am not sure we should simply ignore it.

Pointing to RFCs for RFPs/RFIs and claiming conformance via RFCs will probably be simpler than referring to an IANA registry in this case (i.e. these intervals of this IANA registry).

If we were aiming this document as "standard track", then we definitely want to pursue creation of IANA registry. However, this is an "informational" track document (instructed by RTG directorates) which is simply used as a referenced for "recommendation". Considering there doesn't seem to be strong benefit in creating IANA registry for it at this point, not entirely convinced that we should accompany it with IANA registry.

Is there benefits?

-Nobo

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 8 Apr 2014 16:40:39 +0000

Nobo, and all,
Regarding the structure of the registry (if we go for it) - I'd say that a flat structure (with comments pointing to specific application needs) would suffice. No need to make things more complicated than they are already:-)

Regarding the benefit - a single repository for commonly used values always helps IMO. Of course, you can search Internet for almost everything - but does not this apply to almost all other numbers IANA maintains in its registries today? Starting from such things as special use IPv4 addresses?
RFC 3330 has been published as Informational - but it was authored by IANA, so I suspect (even if I cannot prove it) that there was some kind of e registry for these addresses even in 2002. And it is now obsoleted by RFC 5735 that is a BCP.

My 2c,
     Sasha

________________________________________
From: Nobo Akiya (nobo) <[email-masked]>
Sent: Tuesday, April 8, 2014 5:31 PM
To: Alexander Vainshtein; Carlos Pignataro (cpignata); Donald Eastlake
Cc: [email-masked]
Subject: RE: draft-ietf-bfd-intervals IANA considerations?

Thanks for comments.

Comments inline.

Is there benefits?

-Nobo

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 10 Apr 2014 10:04:46 +0000

Hi, Sasha,

Thanks for the follow-up, please see inline.

> I am not sure I follow the logic of the decision.

I do not think there's a decision yet, only a discussion.

> Donald has already commented on setting a new registry in an Informational document; and saying that new values would be always set via a new draft seems to map well to one of the already existing…

It is clearly possible (and many times desirable) to create or update IANA registries with Informational documents. I've done so myself as well. But "it can be done" does not imply "it should be done".

> But what worries me most is the fact that without a IANA registry there will be no single place where these "common interval values" could be looked up by implementers. Instead, they would have to…

My perspective is that a set of suggested (or recommended) interval/timer values, or default timer values, is not what a numbers registry is used for. Many protocols recommend timer values (TCP, L2TP, etc), but I do not believe those are managed by IANA. Tracking a linked-list of Updated RFCs is not always fun, but in this case I would not expect a long list documents. It also seems to me that when implementing or checking compliance against an RFC, the first place to check is the RFC itself and not an IANA registry.

> I could also say that operators commonly request "compliance" with Informational documents in RFPs and RFIs they publish. (Somebody has recently mentioned requests to comply with some April 1  RFCs…

That's fine but orthogonal to this discussion.

Thanks,

Carlos.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 10 Apr 2014 10:39:54 +0000

Carlos,
Lots of thanks for a prompt and detailed response.

I fully agree with you that "it can be done" does not mean "it should be done".  What I have been trying to say is that, at least in this case we are not dealing with the situation like "thou shalt not..." and not even with "these things are simply not done". 
Any advantages and disadvantages are "in the eye of the beholder" (at least until the document goes to the IESG:-). And would be much easier for me to accept your position if you could expect why you object to requesting a new IANA registry. So far the main argument I see is that you (and presumably the other authors) do not expect many updates to the list of common intervals.

Regards,
       Sasha 
Email: [email-masked]
Mobile: 054-9266302

> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Sent: Thursday, April 10, 2014 1:05 PM
> To: Alexander Vainshtein
> Cc: Donald Eastlake; Nobo Akiya (nobo); [email-masked]
> On Apr 8, 2014, at 12:40 AM, Alexander Vainshtein
> <[email-masked]> wrote:
> 
> > Carlos and all,
> Informational document; and saying that new values would be always set via
> a new draft seems to map well to one of the already existing IANA policies.
> >
> 
> It is clearly possible (and many times desirable) to create or update IANA
> registries with Informational documents. I've done so myself as well. But "it
> can be done" does not imply "it should be done".
> 
> be no single place where these "common interval values" could be looked up
> by implementers. Instead, they would have to track a (potentially long)
> My perspective is that a set of suggested (or recommended) interval/timer
> values, or default timer values, is not what a numbers registry is used for.
> Many protocols recommend timer values (TCP, L2TP, etc), but I do not
> believe those are managed by IANA. Tracking a linked-list of Updated RFCs is
> not always fun, but in this case I would not expect a long list documents. It
> also seems to me that when implementing or checking compliance against an
> RFC, the first place to check is the RFC itself and not an IANA registry.
> 
> >
> > I agree with this as a general statement. As it pertains to the
> > ³Common interval values², it does not appear that is the role of an
> > IANA numbers registry.
> >
> > Thanks,
> >
> > Carlos.
> >
> >> 155 Beaver Street, Milford, MA 01757 USA [email-masked]
> >>
> >>
> >>> Authors of draft-ietf-bfd-intervals have discussed and concluded
> >>> that defined "common intervals set" does _not_ need to be maintained
> by IANA.
> >>>
> >>> Reasons:
> >>> draft-ietf-bfd-intervals creates an IANA registry and defines
> >>> allocation policies for it.
> >>>
> >>> Do you agree with this?

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 10 Apr 2014 11:43:50 +0000

Sasha,

Sorry if I wasn't clear. Like I said, I do not think that a small set of interval values qualifies as something useful to be recorded in an IANA registry.

I do not "object", I just see it as unnecessary overhead, something that does not add value. These is not a namespace of diag codes or auth types. I see no harm (other than busywork) hence not "objecting". 

Do you know of a similar IANA registry? The cases I can think of of suggested protocol timers/periods are *not* managed by IANA. 

Thanks,

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> On Apr 10, 2014, at 6:40 AM, "Alexander Vainshtein" <[email-masked]> wrote:
> 
> Carlos,

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 10 Apr 2014 11:51:15 +0000

Carlos,

The example that comes to my mind (and it is quite personal, you may say that it is not a relevant example for your case) is IPv4 Addresses Space<http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml>.

It is not about timers and (in many cases) not even refers to any RFCs (all records that say “Administered by ARIN/APNIC/AFRINIC etc.”), but it is clearly most useful. And much more difficult for IANA to maintain I think:).

My 2c,

       Sasha

Mobile: 054-9266302

> Sent: Thursday, April 10, 2014 2:44 PM

> Sorry if I wasn't clear. Like I said, I do not think that a small set of interval

> values qualifies as something useful to be recorded in an IANA registry.

> I do not "object", I just see it as unnecessary overhead, something that does

> not add value. These is not a namespace of diag codes or auth types. I see no

> harm (other than busywork) hence not "objecting".

> Do you know of a similar IANA registry? The cases I can think of of suggested

> protocol timers/periods are *not* managed by IANA.

> > On Apr 10, 2014, at 6:40 AM, "Alexander Vainshtein"

> <[email-masked]<mailto:[email-masked]>> wrote:

> > I fully agree with you that "it can be done" does not mean "it should be

> done".  What I have been trying to say is that, at least in this case we are not

> dealing with the situation like "thou shalt not..." and not even with "these

> things are simply not done".

> > Any advantages and disadvantages are "in the eye of the beholder" (at

> least until the document goes to the IESG:-). And would be much easier for

> me to accept your position if you could expect why you object to requesting

> a new IANA registry. So far the main argument I see is that you (and

> presumably the other authors) do not expect many updates to the list of

> common intervals.

> > Email: [email-masked]<mailto:[email-masked]>

> >> Cc: Donald Eastlake; Nobo Akiya (nobo); [email-masked]<mailto:[email-masked]>

> >> <[email-masked]<mailto:[email-masked]>> wrote:

> >> Informational document; and saying that new values would be always

> >> set via a new draft seems to map well to one of the already existing IANA

> >> It is clearly possible (and many times desirable) to create or update

> >> IANA registries with Informational documents. I've done so myself as

> >> well. But "it can be done" does not imply "it should be done".

> >>> But what worries me most is the fact that without a IANA registry

> >>> there will

> >> be no single place where these "common interval values" could be

> >> looked up by implementers. Instead, they would have to track a

> >> (potentially long) sequence of documents in order to understand what

> >> they should try to implement and test.

> >> My perspective is that a set of suggested (or recommended)

> >> interval/timer values, or default timer values, is not what a numbers

> registry is used for.

> >> believe those are managed by IANA. Tracking a linked-list of Updated

> >> RFCs is not always fun, but in this case I would not expect a long

> >> list documents. It also seems to me that when implementing or

> >> checking compliance against an RFC, the first place to check is the RFC

> itself and not an IANA registry.

> >> recently mentioned requests to comply with some April 1  RFCs as well

> >> on the RTG-DIR :-).And while such an argument would not hold in the

> >> court of law, I am not sure we should simply ignore it.

> >>> From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> on behalf of Carlos

> >>> Pignataro

> >>> (cpignata) <[email-masked]<mailto:[email-masked]>>

> >>> Cc: [email-masked]<mailto:[email-masked]>

> >>> From: Donald Eastlake <[email-masked]<mailto:[email-masked]>>

> >>> To: Nobo Akiya <[email-masked]<mailto:[email-masked]>>

> >>> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

> >>>> 155 Beaver Street, Milford, MA 01757 USA [email-masked]<mailto:[email-masked]>

> >>>> On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo)

> <[email-masked]<mailto:[email-masked]>>

> >> wrote:

> >>>>> that defined "common intervals set" does _not_ need to be

> >>>>> maintained

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 10 Apr 2014 15:30:31 +0000

Dear Sasha, Carlos, et. al,
I share Carlos' point of view in regard to creating a new registry for recommended set of BFD intervals. I think that precisely because these values been recommended and none is mandatory creating a registry, IMO, is not necessary. And I'm concerned that if there's such registry then interpretation of the set might change from 'recommended' to 'mandatory'. And that might be reflected in RFPs we'll have to deal with. I for one would not want that to happen.

        Regards,
                Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Thursday, April 10, 2014 4:44 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: draft-ietf-bfd-intervals IANA considerations?

Sasha,

Thanks,

> On Apr 10, 2014, at 6:40 AM, "Alexander Vainshtein" <[email-masked]<mailto:[email-masked]>> wrote:
>
> Carlos,
>> set via a new draft seems to map well to one of the already existing IANA policies.
>>
>> interval/timer values, or default timer values, is not what a numbers registry is used for.
>> checking compliance against an RFC, the first place to check is the RFC itself and not an IANA registry.
>>
>>>
>>>> On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>>>> Hi BFDers,
>>>>>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Apr 2014 13:09:46 -0400

Greg,

On Thu, Apr 10, 2014 at 03:30:31PM +0000, Gregory Mirsky wrote:
> I share Carlos' point of view in regard to creating a new registry for
> recommended set of BFD intervals. I think that precisely because these
> values been recommended and none is mandatory creating a registry, IMO, is
> not necessary. And I'm concerned that if there's such registry then
> interpretation of the set might change from 'recommended' to 'mandatory'.
> And that might be reflected in RFPs we'll have to deal with. I for one
> would not want that to happen.

Personally, I'm ambivalent to whether the registry is created or not.  This
is largely because the simple existence of even an Informational RFC will
have some of the impact you're concerned about.  Adding a registry to permit
the consolidation of changes of future Informational RFCs and the
traceability of why a given interval is recommended won't change whether the
IETF considers such a thing normative or not.

And one must admit the whole point of such a draft in the first place is to
give users a way to say "this is a common value, do you support it?"

-- Jeff