-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Doug
Thanks. I think I get a few more
chances at fixing editorial stuff.
I'll be sure to remember these.
Regards,
Seiichi
Doug Barton wrote:
> On 3/5/2010 4:07 PM, Seiichi Kawamura wrote:
>> Hi Jari
>>
>> ..resending. this time making sure its to
On 3/5/2010 4:07 PM, Seiichi Kawamura wrote:
Hi Jari
..resending. this time making sure its to the 6man list...
I think the points rasied at the IESG teltechat
have been cleared and the 6man WG feels comfortable
with the latest version of the draft.
Will this be placed on the agenda of the next
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jari
..resending. this time making sure its to the 6man list...
I think the points rasied at the IESG teltechat
have been cleared and the 6man WG feels comfortable
with the latest version of the draft.
Will this be placed on the agenda of the next
+1
Lars Eggert wrote:
> Hi,
>
> what Bob outlines below is pretty exactly what I thought the intent of this
> ID was supposed to be, and going in this direction would certainly address my
> discuss.
>
> Lars
>
> On 2010-2-5, at 22:47, Bob Hinden wrote:
>
>> Jari,
>>
>>> Then we talked about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ralph
Ralph Droms wrote:
> Seiichi - I agree that (1) and (2) are appropriate goals for this draft
> and that those two goals have different requirement levels.
>
> It seems to me that there is value in describing the representation and
> the appl
Seiichi - I agree that (1) and (2) are appropriate goals for this
draft and that those two goals have different requirement levels.
It seems to me that there is value in describing the representation
and the application of the standard can be separated, so that the
representation itself is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Bob
There's two things this document asks for.
(1) for people to document IPv6 address in the recommended way.
(2) implementations to display(or save to text/log) IPv6 addresses in the
recommended way.
(1) can never become a MUST. (2), yes but n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Finally catching up to the thread...
It is mentioned in the Appendix that
inet_ntop is a good code reference.
There's also ipv6calc
http://www.deepspace6.net/projects/ipv6calc.html
Regards,
Seiichi
Jari Arkko wrote:
> Mark,
>
>> ISC's inet_ntop() w
Hi,
what Bob outlines below is pretty exactly what I thought the intent of this ID
was supposed to be, and going in this direction would certainly address my
discuss.
Lars
On 2010-2-5, at 22:47, Bob Hinden wrote:
> Jari,
>
>> Then we talked about the strictness. I explained that this is larg
On 2/6/2010 1:40 PM, Brian E Carpenter wrote:
> On 2010-02-06 13:19, Bob Hinden wrote:
>> Doug,
>>
>> On Feb 5, 2010, at 3:59 PM, Doug Barton wrote:
>>
>>> On 2/5/2010 2:37 PM, Brian E Carpenter wrote:
Oh, OK, that is fine for conformance of course, but leaves things
open when you are tal
On 2010-02-06 13:19, Bob Hinden wrote:
> Doug,
>
> On Feb 5, 2010, at 3:59 PM, Doug Barton wrote:
>
>> On 2/5/2010 2:37 PM, Brian E Carpenter wrote:
>>> Oh, OK, that is fine for conformance of course, but leaves things
>>> open when you are talking about generating strings. If we want the
>>> new
Hi Brian,
Brian E Carpenter wrote:
[...]
- Provide a reference to the currently defined WKPs
- In the section that talks about ports, please make sure that for URIs
everyone MUST follow RFC 3986, and for the rest, the default can be
again RFC 3986. The current language leaves everything open, e
Doug,
On Feb 5, 2010, at 3:59 PM, Doug Barton wrote:
> On 2/5/2010 2:37 PM, Brian E Carpenter wrote:
>> Oh, OK, that is fine for conformance of course, but leaves things
>> open when you are talking about generating strings. If we want the
>> new recommendation to be a MUST, we may have to consid
On 2/5/2010 2:37 PM, Brian E Carpenter wrote:
> Oh, OK, that is fine for conformance of course, but leaves things
> open when you are talking about generating strings. If we want the
> new recommendation to be a MUST, we may have to consider wording to
> make it clear how widely it applies. Many ex
On 2010-02-06 10:14, Роман Донченко wrote:
> Brian E Carpenter писал в своём письме
> Sat, 06 Feb 2010 00:04:32 +0300:
>
>> Also, I just came across something "interesting". RFC 3986 cites RFC
>> 2234.
>> In the latter, we find
>> HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
>> Unf
Bob,
On 2010-02-06 09:47, Bob Hinden wrote:
...
> I was thinking that we should have a strict canonical form
> along the line of what is proposed in Section 8. This format
> SHOULD always be used when an IPv6 address is saved to a file
> or log as text (as opposed to binary). The canonical forma
On 2010-02-06 10:09, Alexey Melnikov wrote:
> Hi Brian,
...
>> Also, I just came across something "interesting". RFC 3986 cites RFC
>> 2234.
>> In the latter, we find
>> HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
>> Unfortunately, that means that the URI format (and dependencies s
Brian E Carpenter писал в своём письме Sat,
06 Feb 2010 00:04:32 +0300:
Also, I just came across something "interesting". RFC 3986 cites RFC
2234.
In the latter, we find
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
Unfortunately, that means that the URI format (and dependenci
[repeating with the CC's this time]
On 2010-02-06 01:53, Jari Arkko wrote:
...
> - Use RFC 2119 language and MUST. Implementations conforming to this
> specification MUST ...
No real objection, but its impact of this change in the real world
will be nil IMHO.
> - Provide a reference to the curr
Jari,
> Then we talked about the strictness. I explained that this is largely a
> specification style issue, and in the real world there will always be old
> code that doesn't produce the canonical form, and that we hope that this RFC
> will convince all new code to do the right thing. However,
Mark,
ISC's inet_ntop() was released in 1996 as part of BIND 8. It's also in
BIND 9.
Ah, great! Thanks for the information.
Jari
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ie
In message <4b6c14d2.60...@piuha.net>, Jari Arkko writes:
> This draft was on the IESG review yesterday, and did not get approved
> due to a number of Discusses from the other ADs.
>
> There's a number of small details that we can talk about separately, but
> I wanted to talk to the working gro
The ND Proxy Issues page at
http://www.icir.org/dthaler/NDProxyIssues.htm
has been updated with the new issues raised (16 through 22), as well as
the comments received on each issue.
Issue 19 (Experimental vs Information) is already closed as noted below,
and does not affect the text.
For the r
23 matches
Mail list logo
