[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