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

From: Brian Trammell <[email-masked]>
Date: Mon, 11 Jun 2012 08:36:42 +0200

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 11 Jun 2012 12:55:03 +0200

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-masked]]
> 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...
> 
> 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.)
> 
> > non-interoperability? Brokenly-defined IEs cannot be fixed, they
must
> be
> 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:
> >

---

From: Brian Trammell <[email-masked]>
Date: Mon, 11 Jun 2012 13:21:22 +0200

Hi, Dan,

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

Thanks, best regards,

Brian