Re: [IPFIX] WGLC Comments on draft-ietf-ipfix-ie-doctors

Hi, Dan,

A MAY here seems reasonable given the intent; will make the change.

Thanks, best regards,

Brian

On Jun 11, 2012, at 12:55 PM, Romascanu, Dan (Dan) wrote:

> Hi Brian,
> 
> Thank you for the response. All your responses and proposals seem
> reasonable to me. The only point I would question is #3 - while now the
> intent is clarified, wouldn't it be better to have a MAY rather than a
> SHOULD in '... this column in the registry MAY contain the private
> enterprise and Information Element numbers of the enterprise-specific
> version of the Information Element.'
> 
> Regards,
> 
> Dan
> 
> 
>> -----Original Message-----
>> From: Brian Trammell [mailto:[email protected]]
>> Sent: Monday, June 11, 2012 9:37 AM
>> To: Romascanu, Dan (Dan)
>> Cc: IETF IPFIX Working Group
>> Subject: Re: [IPFIX] WGLC Comments on draft-ietf-ipfix-ie-doctors
>> 
>> Hi, Dan,
>> 
>> Many thanks for your review; comments on comments inline. I'm applying
>> changes to a post-WGLC revision to be submitted shortly...
>> 
>> On May 24, 2012, at 5:00 PM, Romascanu, Dan (Dan) wrote:
>> 
>>> 2. Section 4.3 talks about the need to designate an expert to advice
>> to
>>> IANA on Netflow v9 matters. This request is not however mentioned in
>> the
>>> IANA Considerations section.
>> 
>> Fixed.
>> 
>>> 3. It is not clear to me what is the goal of the following piece of
>>> process described in Section 4.9:
>>> 
>>>> In order to support transition from experimental registration to
>> IANA
>>>  registration, the IANA registry provides an optional "enterprise-
>>>  specific IE reference" column for each Information Element.  In
>> cases
>>>  of promoted enterprise-specific Information Elements, this column
>> in
>>>  the registry SHOULD contain the private enterprise and Information
>>>  Element numbers of the enterprise-specific version of the
>> Information
>>>  Element.
>>> 
>>> If I understand well, an IE shows up in the IANA registry only when
> a
>>> standard IE is added to the registry. What 'transition' is being
>>> supported here, and how is it supported by a back reference to a
>>> proprietary enterprise registry?
>> 
>> The idea is that proprietary enterprise registries are not necessarily
>> unpublished. The transition envisioned is of experimental or research
>> applications to production, as in the SIPCLF work, which defined
>> information elements during the draft stage in PEN 35566 so that
>> initial implementation could proceed without adding IEs to IANA before
>> the work published as an RFC (which, indeed, it hasn't been, as it
>> wasn't adopted by the WG.)
>> 
>>> 4. In Section 5.2, the following change in an IE is considered to be
>>> interoperable:
>>> 
>>>> it corrects an ambiguity in the Information Element's definition,
>>>     which itself leads to non-interoperability (e.g., a prior
> change
>>>     to ipv6ExtensionHeaders)
>>> 
>>> How can an IE with a corrected definition be interoperable with an
> IE
>>> with a definition that is that broken that it leads to
>>> non-interoperability? Brokenly-defined IEs cannot be fixed, they
> must
>> be
>>> deprecated and new IEs defined with a different name to start with.
>> 
>> This class of change was primarily included as it reflected a revision
>> which has already been done. The reasoning here is that, as the IE was
>> originally defined in a broken way, there is no net total negative
>> interoperability impact from redefining it to correct the ambiguity.
>> However, this does make the implicit assumption that implementors are
>> paying attention to information element updates.
>> 
>>> 5. Also in 5.2:
>>> 
>>>> A non-interoperable Information Element change may also be made if
>> it
>>>  can be reasonably assumed in the eyes of the appointed experts
> that
>>>  no unchanged implementation of the Information Element exists;
> this
>>>  can be held to happen if a non-interoperable change to an
>> Information
>>>  Element defined shortly before is proposed to the IPFIX mailing
>> list
>>>  by the original proposer of the Information Element, and no
>> objection
>>>  is raised within a reasonable amount of time, to be defined by the
>>>  expert reviewers.
>>> 
>>> I strongly oppose this. We need to assume that the IANA registry is
>>> universally visible and that people who never read the IPFIX mailing
>>> list can write applications using IEs. Hence there  is no
>> 'reasonable'
>>> assumption like the one described here. A non-interoperable change
>> must
>>> be performed by deprecating the old IE and defining a new IE with a
>>> different name.
>> 
>> Put that way, I would tend to agree; we can remove this.
>> 
>>> 6. In 5.3:
>>> 
>>>> Names
>>>  of obsolete Information Elements MAY be reused, but this is NOT
>>>  RECOMMENDED, as it may cause confusion among users.
>>> 
>>> No, please not! Do not reuse names of obsolete IEs, you can never
>> know
>>> what older applications are being deployed and run.
>> 
>> Point, as above; removed.
>> 
>>> 7. You may consider to recommend in the Security Considerations
>> sections
>>> that IETF documents that define new IEs list in their Security
>>> Considerations sections the IEs that have specific security aspects
>>> mentioned in descriptions, or their semantics or their usage can
>>> generate or are prone to security vulnerabilities.
>> 
>> Good point; done.
>> 
>> Best regards,
>> 
>> Brian

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix