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

"Romascanu, Dan (Dan)" <[email protected]>
Newsgroups gmane.ietf.ipfix
Message-ID <EDC652A26FB23C4EB6384A4584434A0407A4FA5D@307622ANEX5.global.avaya.com>
Hi,

Please find below my Working Group Last Call comments on
draft-ietf-ipfix-ie-doctors-02:

1. Editorial cleaning - The I-D needs a serious round of editorial
cleaning performed by a native English speaker. 

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. 

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? 

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. 

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. 

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. 

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.  

Regards,

Dan

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.