On Fri, May 24, 2013 at 3:27 PM, Michael Sweet wrote:
> Kerry,
>
> On 2013-05-24, at 2:51 PM, Kerry Lynn wrote:
>
> ...
>
> Just so we're clear, I assume this does NOT work today with link-local
> IPv6 addresses (because no print client yet
> constructs a Host
On Fri, May 24, 2013 at 2:27 PM, Michael Sweet wrote:
> Christian,
>
> On 2013-05-24, at 1:45 PM, Christian Huitema
> wrote:
> > Can we move from the process discussion to the technical discussion?
> >
> > Michael raised an interesting issue, and we have to analyze it. The
> consensus of the wor
Michael,
Can I echo what Tom and Christian have said - that you join the 6man working
group and start by clearly and concisely stating the problem that this RFC
poses
for your application and how you suggest we fix it?
When you speak of "hundreds of millions of printers..." it gives the
impressio
On Mon, Feb 11, 2013 at 2:32 AM, Jitendra Singh <
jitendra.bhador...@one97.net> wrote:
> Hi,
>
> ** **
>
> I am trying to write an IPv6 client in C++ using ACE framework. Even after
> compiling with ACE_HAS_IPV6 preprocessor flag, I am not able to connect to
> an IPv6 server.
>
> Can someb
On Tue, Aug 14, 2012 at 10:41 AM, Ole Trøan wrote:
> all,
>
> I fully accept that there are no perfect solution to this problem.
> given that we are were we are...
> it appears there is consensus building around Stuart's proposal.
>
> that entails:
> - encode '%' as "%25"
> - advocate that URI
On Thu, Aug 2, 2012 at 12:29 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Thu, Aug 02, 2012 at 11:10:40AM +0100, Brian E Carpenter wrote:
>
> > > I see no value in introducing a new separator.
> >
> > The value is providing a long-term path to cut and paste. Otherw
On Wed, Jun 27, 2012 at 1:53 PM, Stig Venaas wrote:
> On 6/27/2012 10:13 AM, Kerry Lynn wrote:
>
>> Greetings,
>>
>> RFC 3484 section 3.1 defines "subnet-local (0x03)" multicast scope, but
>> later RFC 4291 section 2.7 defines this multicast scope valu
Greetings,
RFC 3484 section 3.1 defines "subnet-local (0x03)" multicast scope, but
later RFC 4291 section 2.7 defines this multicast scope value as reserved.
Can I ask if the later interpretation is the correct one?
I ask in the context of e.g.
http://tools.ietf.org/html/draft-lynn-homenet-site-m
On Fri, May 4, 2012 at 10:10 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Fri, May 04, 2012 at 09:54:36AM -0400, Simon Perreault wrote:
> > On 2012-05-04 09:44, Juergen Schoenwaelder wrote:
> > >On Fri, May 04, 2012 at 08:29:11AM -0500, Rajiv Asati (rajiva) wrote:
On Wed, May 2, 2012 at 9:55 AM, Ole Trøan wrote:
> Kerry,
>
> apologies for sending this to you direct. partially a person interest (as
> I'm refurbishing a house), but also of professional interest.
>
> with regards to the various building control system standards. are BACnet,
> instabus, EIB, K
On Sun, Apr 29, 2012 at 3:54 AM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> Hi,
>
> In the IETF 83 discussion of draft-ietf-6man-uri-zoneid-00,
> there was no clear consensus on the approach to pursue. In fact,
> almost the same discussion occurred around draft-fenner-literal-zone
>
On Thu, Mar 29, 2012 at 12:02 PM, Iljitsch van Beijnum
wrote:
> On 28 Mar 2012, at 12:08 , Fred Baker wrote:
>
> >> I haven't read the spec yet, but isn't PCP supposed to work in the
> service provider run NAT64/CGN case, too? In that case, the multicasts need
> to escape out of the site or even o
On Sat, Mar 17, 2012 at 2:22 AM, Dave Thaler wrote:
> Brian Carpenter writes:
> [...]
>> Let me be clear. If a local service has (for some reason) both a ULA and a
>> non-
>> ULA global address, and the host has both, I think the correct default
>> behaviour is for the ULA address pair to be used
of length 8, allow the ISP to assign 64bit prefix to leaf
> network, and let the gateway in between to derive prefixes out of that
> 64bit (up to 120) and still use SLAAC.
>
> This is just a thought, not a request to modify.
>
> Yours,
>
> Alex
>
> Le 13/03/2012 12:47
IETF.
>
> Title : Transmission of IPv6 over MS/TP Networks
> Author(s) : Kerry Lynn
> Jerry Martocci
> Carl Neilson
> Stuart Donaldson
> Filename : draft-ietf-6man-6lobac-01.txt
On Wed, Mar 7, 2012 at 8:50 AM, Carsten Bormann wrote:
> On Mar 7, 2012, at 16:29, Kerry Lynn wrote:
>
>> And hopefully coap://[v6.fdfd::1]/... would work as well?
>
> Oh. That may be a reason to go with v1, not v6...
>
> I don't think the idea is to *replace* IPv6a
On Wed, Mar 7, 2012 at 7:11 AM, Carsten Bormann wrote:
> On Mar 7, 2012, at 15:22, Bill Fenner wrote:
>
>>> RFC 3986 is not sacred.
>>
>> Of course it's not sacred.
>
> Not sacred, but is is also not open for gratuitous changes.
>
> I don't see a technical reason to do anything else than what you
On Wed, Mar 7, 2012 at 6:22 AM, Bill Fenner wrote:
> On Mar 6, 2012, at 5:44 PM, Brian E Carpenter
> wrote:
>
>> On 2012-03-07 11:26, Carsten Bormann wrote:
>>> On Mar 6, 2012, at 23:08, Brian E Carpenter wrote:
>>>
Was there a real reason that you went for this?
IPv6zone-id = 1*( unres
On Tue, Mar 6, 2012 at 2:43 PM, Carsten Bormann wrote:
> Given Bill's draft, we may not have to argue this, but:
>
> On Mar 6, 2012, at 01:15, Brian E Carpenter wrote:
>
>> The ABNF does not describe the produced (encoded)
>> URI.
>
> That is certainly *not* my understanding of RFC 3986.
>
> (It i
Aye, -K-
On Wed, Feb 8, 2012 at 2:51 PM, Brian Haberman wrote:
> All,
> This is a consensus call on adopting:
>
> Title : Representing IPv6 Zone Identifiers in
> Uniform Resource Identifiers
> Author(s) : Brian Carpenter
> Robert M. Hinden
> Fil
On Tue, Nov 22, 2011 at 4:56 PM, Kerry Lynn wrote:
>
> On Tue, Nov 22, 2011 at 3:52 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
>
>> On 2011-11-23 05:34, Philip Homburg wrote:
>> > In your letter dated Tue, 22 Nov 2011 14:30:03 +1100 you wrote:
On Tue, Nov 22, 2011 at 3:52 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> On 2011-11-23 05:34, Philip Homburg wrote:
> > In your letter dated Tue, 22 Nov 2011 14:30:03 +1100 you wrote:
> >> On a related issue to link locals in URI's, we don't currently have
> >> a good method of s
On Thu, Nov 17, 2011 at 9:27 PM, Tomoyuki Sahara wrote:
> Hi,
>
> That sounds good to me too.
>
> > My ABNF is pretty rusty, so I offer the following extension to the RFC
> 3986
> > IPv6address rule only as a starting point:
> > / "FE80::" [ *3( h16 ":" ) h16 ] [ "%" 1*4(ALPHA / DIGIT) ]
>
> I ha
On Thu, Nov 17, 2011 at 12:13 AM, Carsten Bormann wrote:
> On Nov 17, 2011, at 13:00, Brian E Carpenter wrote:
>
> > Do people agree that this is a reasonable thing to do?
>
> Yes please!
>
> My ABNF is pretty rusty, so I offer the following extension to the RFC 3986
IPv6address rule only as a st
Greetings,
I've noticed that a "bug" has re-appeared in Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=700999
In older versions of Firefox (e.g. 3.6.23) it is possible to enter URIs of
the form http://[fe80::206:98ff:fe00:232%tap0] in the
location bar and get a positive result. This capab
I support adoption of this draft as a 6MAN WG document.
-K-
On Tue, Oct 11, 2011 at 1:05 PM, Brian Haberman wrote:
> All,
> This is a consensus call on adopting:
>
> Title : RFC3627 to Historic status
> Author(s) : Wesley George
> Filename : draft-george-6man-3627-historic-
, ker...@ieee.org,
jerald.p.marto...@jci.com, cneil...@deltacontrols.com
A new version of I-D, draft-lynn-6man-6lobac-02.txt has been successfully
submitted by Kerry Lynn and posted to the IETF repository.
Filename:draft-lynn-6man-6lobac
Revision:02
Title: Transmission of
On Mon, Sep 19, 2011 at 7:02 PM, Brian E Carpenter
wrote:
> On 2011-09-20 09:23, Nathan Ward wrote:
>> On 20/09/2011, at 9:19 AM, Iljitsch van Beijnum wrote:
>>
>>> My position is that prefixes should always end in :: so the address part is
>>> a valid address and the same code can be used to par
RFC 3306 states:
"The scope of the unicast-prefix based multicast address MUST NOT
exceed the scope of the unicast prefix embedded in the multicast
address."
I'd just like to verify my interpretation that site-local multicast addresses
MAY be formed from ULA prefixes? If so, should a particul
On Tue, Jul 26, 2011 at 6:03 PM, Alexandru Petrescu <
alexandru.petre...@gmail.com> wrote:
> Comments on draft draft-lynn-6man-6lobac-00:
>
> - needs a section on multicast address mapping; it may not be
> straightforward: it may need to _not_ send all ip-multicasted messages to
> 255 link-layer
Brian, you're quite right. I had in mind only one particular class of IID.
Washam, see Appendix A of RFC 4291 regarding modified EUI-64 IIDs
with "u"=0. Also, RFC 3041 has been obsoleted; see RFC 4941 and
its errata if privacy issues apply in your situation.
-K-
On Fri, Jul 15, 2011 at 6:25 P
See also section 2.5.4 of RFC 4291:
"All Global Unicast addresses other than those that start with binary
000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
described in Section 2.5.1."
So I'd say the answer is the IID MUST be 64 bits long, and MUST
satisfy the properties of u
Mon, Jul 4, 2011 at 6:17 PM
Subject: New Version Notification for draft-lynn-6man-6lobac-00.txt
To: ker...@ieee.org
Cc: ker...@ieee.org
A new version of I-D, draft-lynn-6man-6lobac-00.txt has been successfully
submitted by Kerry Lynn and posted to the IETF repository.
Filename:draft-lynn
33 matches
Mail list logo
