HEllo, and thank you for this draft.

I have been following it and I mostly agree with the technical content.
 No restrain there.

However, I have a strong doubt with respect to the licensing scheme of
this draft: its preamble requires "Code Components" within to be
"Simplified BSD License".

I would suggest to rather have no such licensing scheme for this draft,
mostly because other licenses may be more appropriate for this
particular draft (for example, if it gets implemented in GNU Libc then
it would want to be GPL, not BSD, not a combination).

I understand it may be that there may be no Code Components in this
draft.  However, when I read it I feel precisely how to code it.  When
coding it, the "::" string is part of the code.

I also understand the preamble (boilerplate) is an IETF Trust rule
applied throughout.  TO which I am bound to agree.

Respectfully,

Alex

Le 17/02/2010 03:50, Seiichi Kawamura a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi

I have uploaded the new version of the draft. I hope this addresses
the issues that were raised.

I have removed the Conclusion part since Section 4 is now clear and
concise. Thank you Ron, for providing good text in IESG COMMENT.

Regards, Seiichi


internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IPv6 Maintenance
Working Group of the IETF.


Title           : A Recommendation for IPv6 Address Text
Representation Author(s)       : S. Kawamura, M. Kawashima Filename
: draft-ietf-6man-text-addr-representation-05.txt Pages           :
14 Date            : 2010-02-16

As IPv6 network grows, there will be more engineers and also non-
engineers who will have the need to use an IPv6 address in text.
While the IPv6 address architecture RFC 4291 section 2.2 depicts a
flexible model for text representation of an IPv6 address, this
flexibility has been causing problems for operators, system
engineers, and users.  This document will describe the problems
that a flexible text representation has been causing.  This
document also recommends a canonical representation format that
best avoids confusion.  It is expected that the canonical format is
followed by humans and systems when representing IPv6 addresses as
text, but all implementations must accept and be able to handle any
legitimate RFC4291 format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-text-addr-representation-05.txt



Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------------------------------------------------------------------------



--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkt7WZEACgkQcrhTYfxyMkKWVQCfd7Lda1L7plEKiaWSRD48V+kt
9qIAn3BQ5BjrcOit0U7vPaXnVgkmC/yg =Sifs -----END PGP SIGNATURE-----
--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to