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

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