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

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 10 Apr 2014 18:14:42 +0000

Dear Greg,

I think that the values listed in this draft will ultimately find their way to RFPs regardless of creation (or non-creation) of the registry.

And while the draft is Informational, it is quite convincing in explaining that support of this set of values is important for achieving ineroperability... Which makes it quite reasonable for the operators to request that these values are supported.

My 2c,

Sasha

Sent from my LG Mobile

------ Original message ------
From: Gregory Mirsky
Date: 10/04/2014 18:30
To: Carlos Pignataro (cpignata);Alexander Vainshtein;
Cc: [email-masked];
Subject:RE: draft-ietf-bfd-intervals IANA considerations?

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,

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]<mailto:[email-masked]>> wrote:
>
> 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]<mailto:[email-masked]>
> Mobile: 054-9266302
>
>> -----Original Message-----
>> 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]<mailto:[email-masked]>
>> Subject: Re: draft-ietf-bfd-intervals IANA considerations?
>>
>> Hi, Sasha,
>>
>> Thanks for the follow-up, please see inline.
>>
>> On Apr 8, 2014, at 12:40 AM, Alexander Vainshtein
>> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> Carlos and all,
>>> 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 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".
>>
>>> 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.
>> 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 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.
>>
>> That's fine but orthogonal to this discussion.
>>
>> Thanks,
>>
>> Carlos.
>>
>>> My 2c,
>>>    Sasha
>>>
>>>
>>>
>>> ________________________________________
>>> From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> on behalf of Carlos
>>> Pignataro
>>> (cpignata) <[email-masked]<mailto:[email-masked]>>
>>> Sent: Tuesday, April 8, 2014 6:11 AM
>>> To: Donald Eastlake; Nobo Akiya (nobo)
>>> Cc: [email-masked]<mailto:[email-masked]>
>>> Subject: Re: draft-ietf-bfd-intervals IANA considerations?
>>>
>>> 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]<mailto:[email-masked]>>
>>> Date: Monday, April 7, 2014 at 11:05 PM
>>> To: Nobo Akiya <[email-masked]<mailto:[email-masked]>>
>>> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>>> Subject: Re: draft-ietf-bfd-intervals IANA considerations?
>>>
>>>> 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]<mailto:[email-masked]>
>>>>
>>>>
>>>> On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>>>> 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: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 11 Apr 2014 17:45:46 +0000

[history of the draft]
- This document used to be standard track.
- Several folks were opposed to the document being standard track.
- Many (including those who opposed as standard track) were supportive of the document being informational.
- Document changed to informational from -04 of individual document.

Thus, technically, proposed intervals will only be "recommended" set of intervals.

[Sasha wrote]
> I think that the values listed in this draft will ultimately find their way to
> RFPs regardless of creation (or non-creation) of the registry.

[Jeff wrote]
> 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?"

And as you Sasha and Jeff stated, it will be up to vendors/operators to get the "recommended" interval set in implementations to improve interoperability, via pointing to this draft.

Neither of above are relevant of whether or not we need IANA registry for "recommended" interval set, but felt that they'll provide some use to those just starting to read this thread/draft.

As for IANA, I believe we have 3 approaches.
1. Create IANA registry with this draft.
2. Do not create IANA registry with this draft.
3. Do not create IANA registry with this draft, but create IANA registry with future draft if/when we foresee [multiple] updates to "recommended" interval set and we converge that having IANA maintenance will be beneficial.

Since there are opinions for both (1) and (2), with more folks arguing for (2), perhaps approach (3) might be a reasonable middle ground?

-Nobo

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Alexander
> Vainshtein
> Sent: Thursday, April 10, 2014 2:15 PM
> To: Gregory Mirsky; Carlos Pignataro (cpignata)
> Cc: [email-masked]
> I think that the values listed in this draft will ultimately find their way to
> RFPs regardless of creation (or non-creation) of the registry.
> And while the draft is Informational, it is quite convincing in explaining that
> support of this set of values is important for achieving ineroperability...
> Which makes it quite reasonable for the operators to request that these
> values are supported.
> My 2c,
> Sasha
> 
> Sent from my LG Mobile
> 
> 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
> 
> 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,
> 
> > On Apr 10, 2014, at 6:40 AM, "Alexander Vainshtein"
> <[email-masked]> wrote:
> >
> > Carlos,
> > 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
> >
> >> Cc: Donald Eastlake; Nobo Akiya (nobo);  [email-masked]
> >> <[email-masked]> wrote:
> >>
> >>> Carlos and all,
> >>> From: Rtg-bfd <[email-masked]> on behalf of Carlos
> >>> Pignataro
> >>> (cpignata) <[email-masked]>
> >>> From: Donald Eastlake <[email-masked]>
> >>> To: Nobo Akiya <[email-masked]>
> >>> Cc: "[email-masked]" <[email-masked]>
> >>>> 155 Beaver Street, Milford, MA 01757 USA  [email-masked]
> >>>>
> >>>>
> >>>> On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) <[email-masked]>
> >> wrote:
> >>>>> Hi BFDers,
> >>>>>