SGN1 – Rereading sheet on draft SARPs IP SNDCF

Paper information / Paper from Tony WHYMAN
Version 1.3 - 18/10/2002
Ref : DIS/COM/ProATN_Sup/DCI/AW_116
Remarks from / Leon Sayadian / Responses from / Pierre Vabre – STNA
e-mail / [HD1] / e-mail /
Date of the remarks / 7/7/04 / Date of the responses / 18/10/2004
N°[HD2] / Ref[HD3] / Type[HD4] / Remark / Response / SGN1 decision needed[HD5]
Agree[HD6] / Comments
1.3 / Editorial / All references should be dated for consistency. / Y / RFC references are unambiguous (no update of the content once the RFC number is assigned).
However, a date column has been added for informational purpose.
This comment brings some additional remarks, that need also to be accommodated:
- In the current draft, the table is not expected to be integrated in the ICS SARPs.
- But references to this table are sometimes made in the proposed SARPs text (some other times, text reference directly RFCs).
The proposed text is updated to incorporate the table and always reference base standards through this table.
Note: this enforces renumbering of chapters 5.7.10.2 and below. / N
1.3, Ref. 12 / Technical / RFC 2373 is obsolete, replace with RFC 3513 / Y / Done / N
General / Arrows in figures indicating data flow should be bi-directional (e.g., Figure 5.7-21) / Y / Done / N
5.7.10.2.1.1 / Technical / Add reference to RFC 796 here, and list in Section 1.3 / Y / RFC 796 specifies a classification of IPv4 addresses and also some address mapping from IP to old ancient network technology.
RFC 796 classification has been aged by the introduction of CIDR (RFC 1519), known also as Variable Length Subnet Mask (VLSN).
Anyway, IP SNDCF is only required to make use of RFC 791 conforming IPv4 addresses (i.e. 32-bit addresses). There is no need in the IP SNDCF to over specify the IPv4 address format. The structure of the address should be left as a local issue for the IP network designer and/or administrator.
As a consequence, the remark is taken into account as a note, and only for informational purpose. / N
5.7.10.2.1.2 / Technical / Add reference [12] from Section 1.3. See Comment #2 / Y / IP SNDCF is only required to make use of RFC 2460 conforming IPv6 addresses (i.e. 16-octet addresses). There is no need in the IP SNDCF to over specify the IPv6 address format. The structure of the address should be left as a local issue for the IP network designer and/or administrator.
As a consequence, the remark is taken into account as a note, and only for informational purpose. / N
Page 5, subparagraph g & Par. 1.3, Ref. 14 / Add RFC 3260 to update terminology. / Y / Note after g has been updated and rephrased. A note has also been added after f) and an ambiguity fixed in e) and f). / N
5.7.10.4 / Technical / The version of ICMP under discussion is not defined (v4 or v6?) / Y / Most of the proposed text applies indifferently to ICMPv4 and ICMPv6 (the only exception being the ICMPv4 specific source quench message).
Note 2 added (and existing note renamed) at beginning of 5.7.10.4. / N

page 1/3

[HD1]1easy way to contact proper people, for example in case of understanding problem with the remark.

[HD2]1automatic remark number.

[HD3]1page inside the document in pdf format and § number.

[HD4]1m for minor comment (typo, language….) M for Major comment.

[HD5]1If SME does not agree the remark and if the provided comments does not answer the concern on a major remark, SGN1 decision is needed ; otherwise NO.

[HD6]1Y for YES : means the remark will be taken into account. N for NO : means the remark is not agreed by the SME. Explanations inside the comments.