headers
Kerry Lynn | 2 May 2012 16:44
Picon

Re: Building control standards

On Wed, May 2, 2012 at 9:55 AM, Ole Trøan <otroan <at> employees.org> 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, KNX all basically the same, and covered by draft-ietf-6man-6lobac-01?

cheers,
Ole

Hi Ole,

No problem.  I am not familiar with some of the standards you mention.
The problem comes in when these "last meters" protocols develop their own
proprietary data links.  BACnet is in that camp currently with MS/TP, which
is one of several data links that it supports but the only one that does not
already have a "IPv6 over foo" RFC.  As the larger vision is to transition
BACnet to native IPv6 in the future, I believe that draft-ietf-6man-6lobac
is a necessary step on that path since it is so widely deployed in commercial
building automation systems.  It is about a factor of 10 less costly than
ethernet per driver, can cover long distances (1000-1200 m), and has a
sufficient data rate for the BAC application (up to 115.2 kpbs).

That said, in conjunction with changes being made in parallel to the data
link (through a BACnet standard change proposal), I think that MS/TP can
fill a niche at the low end of wired data links (similar to the niche that 6LoWPAN
fills in wireless) and will transport arbitrary IPv6 packets up to 1500 octets
in length (not including the IPHC dispatch header, and depending on link
MTU setting).  To the extent that the standards you mention will exchange
their application data using standard IP transports, and the required data
rate is 115.2 kbps or less, then IPv6 over MS/TP should be a viable option.

Hope that answers your question, -K-


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
Ole Trøan | 2 May 2012 16:53
Favicon

Re: Building control standards

Kerry,

> No problem.  I am not familiar with some of the standards you mention.
> The problem comes in when these "last meters" protocols develop their own
> proprietary data links.  BACnet is in that camp currently with MS/TP, which
> is one of several data links that it supports but the only one that does not
> already have a "IPv6 over foo" RFC.  As the larger vision is to transition
> BACnet to native IPv6 in the future, I believe that draft-ietf-6man-6lobac
> is a necessary step on that path since it is so widely deployed in commercial
> building automation systems.  It is about a factor of 10 less costly than
> ethernet per driver, can cover long distances (1000-1200 m), and has a
> sufficient data rate for the BAC application (up to 115.2 kpbs).
> 
> That said, in conjunction with changes being made in parallel to the data
> link (through a BACnet standard change proposal), I think that MS/TP can
> fill a niche at the low end of wired data links (similar to the niche that 6LoWPAN
> fills in wireless) and will transport arbitrary IPv6 packets up to 1500 octets
> in length (not including the IPHC dispatch header, and depending on link
> MTU setting).  To the extent that the standards you mention will exchange
> their application data using standard IP transports, and the required data
> rate is 115.2 kbps or less, then IPv6 over MS/TP should be a viable option.

thanks for your quick reply!
KNX also refers to ANSI/ASHRAE 135   (http://www.knx.org/knx-standard/introduction/)
so I can only hope that the work on MS/TP will also cover Europe.

cheers,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Brian Haberman | 2 May 2012 20:52

AD review: draft-ietf-6man-lineid

All,
      Here are my comments on the LineID draft.  It is in pretty good 
shape, but I would like these issues addressed before moving on to IESG 
Review/IETF Last Call...

Substantive
-----------

- Section 2 (paragraph 3) : This text talks about "the network" getting 
some information from the subscriber-originated RS messages.  Is it 
really the AN that gets this information or is it really the Edge 
Router?  What information is being lost when the subscriber-initiated RS 
messages stop?

- Section 2 (paragraph 5) : This paragraph states that this approach is 
"NOT RECOMMENDED for general deployments".  Do you really mean general 
deployments or is is better to say deployments not using the N:1 VLAN model?

- Section 5.1 : If the AN has an IPv6 address, why is its use in the 
encapsulating header only a SHOULD?

- Section 6.3 : How does the edge router know what prefixes to map to 
the LIO?  Should there be some specification that the RA transmitted 
must/should carry a PIO?

- Section 7 : I would suggest for the definition of the Option Length 
s/The value 0 is considered invalid/The value MUST be greater than 0/

- Section 7.1 : I have questions on the use of SHOULD NOT in the last 
two paragraphs. In what situation would two line IDs be considered equal 
if they do not match byte-by-byte?  To me, this can be changed to MUST 
NOT. I am not sure there is really any reason to say an intermediate 
system SHOULD NOT examine the Line ID.  There is no way to enforce that 
rule.  In what situation (or type of situation) would an intermediate 
system be allowed to modify the Line ID?

Editorial
---------

* Introduction
- s/traditionally/traditional/
- s/[RFC1661] based some networks/[RFC1661] based, some networks/
- s/network in context/network in the context/
- None of the figures are referenced in the text
- Expand GPON acronym on its first use

* Terminology
- The definition of AN uses the terms northbound and southbound. It 
would be useful to briefly define those (or use different terms).
- I would define RG before Edge Router so that there is no dangling use 
of the term RG before it is defined. Or you can expand RG in the 
definition...
- It may be useful to state whether the use of an RG is optional or not.
- The definition of RG is missing a term: "...similar to one specified 
in or a Layer...".

* Section 2
- s/VLAN deployment models line/VLAN deployment models, line/
- DHCP should be expanded on first use and a reference given.
- I would suggest providing a reference for SLAAC.
- s/this results on some/this results in some/
- s/Router Solicitations by initiating RSs/Router Solicitations (RSes) 
by initiating RSes/
- s/RSs/RSes/g
- There is a dangling "e.g." in the middle of the third paragraph.

* Section 3
- s/the end-device on the circuit the end-device is connected on/the 
end-device on the circuit/
- It would be useful to include a reference for DHCP relay agents.

* Section 4
- The acronym ND needs to be expanded or changed to RS/RA.
- Specify that it is the Hop Limit of the *inner* packet that must not 
be decremented.

* Section 5.1
- The section uses the term "insert" when talking about the creation of 
the encapsulating (outer) packet.  This makes me think of modifying an 
existing packet.  It would be clearer to state that the encapsulating 
packet includes/contains a destination options header.

* Section 5.2
- s/router advertisement/Router Advertisement/
- Rather than saying the AN will "multicast" the inner packet, would be 
sufficient to say it will "transmit" the inner packet?

* Section 6.1
- Last sentence is missing a period.

* Section 6.2
- s/this router advertisement(es./this router advertisement./
- s/All BBF Access Nodes/All-BBF-Access-Nodes/g

* Section 6.3
- Provide an informative reference for ANCP.

* Section 7
- s/an alignment requirement of (none)/no alignment requirements/

* Section 7.1
- The last sentence of the first paragraph is missing a period.

Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
George, Wes | 3 May 2012 17:42

RE: 6MAN WG Last Call: <draft-ietf-6man-rfc3484bis-02.txt>

Apologies on missing the cutoff, but I made the recommendation at the mic in Paris that this needed to say
something referencing RFC 6598 and how those addresses are to be treated. I just got around to checking and
it seems to have been missed in this revision.

Thanks,

Wes

> -----Original Message-----
> From: ipv6-bounces <at> ietf.org [mailto:ipv6-bounces <at> ietf.org] On Behalf Of Bob
> Hinden
> Sent: Thursday, April 12, 2012 5:28 PM
> To: ipv6 <at> ietf.org Mailing List
> Cc: Bob Hinden
> Subject: 6MAN WG Last Call: <draft-ietf-6man-rfc3484bis-02.txt>
>
> All,
>
> This message starts a two week 6MAN Working Group on advancing:
>
>       Title           : Default Address Selection for Internet Protocol
> version 6 (IPv6)
>       Author(s)       : Dave Thaler
>                           Richard Draves
>                           Arifumi Matsumoto
>                           Tim Chown
>       Filename        : draft-ietf-6man-rfc3484bis-02.txt
>       Pages           : 30
>       Date            : 2012-04-11
>
>         http://tools.ietf.org/html/draft-ietf-6man-rfc3484bis-02
>
> as Proposed Standard.  Substantive comments and statements of support for
> advancing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the authors.  This last call will
> end on April 26, 2012.
>
> Regards,
> Ole Troan & Bob Hinden
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 <at> ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is
privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is
intended solely for the use of the individual or entity to which it is addressed. If you are not the intended
recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or
action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may
be unlawful. If you have received this E-mail in error, please notify the sender immediately and
permanently delete the original and any copy of this E-mail and any printout.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
Dave Thaler | 4 May 2012 01:57
Picon
Favicon

RE: 6MAN WG Last Call: <draft-ietf-6man-rfc3484bis-02.txt>

It already says "Other IPv4 addresses are assigned global scope."
And since RFC 1918 addresses are treated as globals too, saying 6598 is treated like
any other global address didn't seem necessary.   Still, in response to this email, I'm
changing to:
	"Other IPv4 addresses (including IPv4 private addresses [RFC1918] and 
	Shared Address Space addresses [RFC6598]) are assigned global scope."
in -03, which at least makes it clear that this was intentional.

-Dave

> -----Original Message-----
> From: ipv6-bounces <at> ietf.org [mailto:ipv6-bounces <at> ietf.org] On Behalf Of
> George, Wes
> Sent: Thursday, May 03, 2012 8:43 AM
> To: Bob Hinden; ipv6 <at> ietf.org Mailing List
> Subject: RE: 6MAN WG Last Call: <draft-ietf-6man-rfc3484bis-02.txt>
> 
> Apologies on missing the cutoff, but I made the recommendation at the mic in
> Paris that this needed to say something referencing RFC 6598 and how those
> addresses are to be treated. I just got around to checking and it seems to have
> been missed in this revision.
> 
> Thanks,
> 
> Wes
> 
> > -----Original Message-----
> > From: ipv6-bounces <at> ietf.org [mailto:ipv6-bounces <at> ietf.org] On Behalf
> > Of Bob Hinden
> > Sent: Thursday, April 12, 2012 5:28 PM
> > To: ipv6 <at> ietf.org Mailing List
> > Cc: Bob Hinden
> > Subject: 6MAN WG Last Call: <draft-ietf-6man-rfc3484bis-02.txt>
> >
> > All,
> >
> > This message starts a two week 6MAN Working Group on advancing:
> >
> >       Title           : Default Address Selection for Internet Protocol
> > version 6 (IPv6)
> >       Author(s)       : Dave Thaler
> >                           Richard Draves
> >                           Arifumi Matsumoto
> >                           Tim Chown
> >       Filename        : draft-ietf-6man-rfc3484bis-02.txt
> >       Pages           : 30
> >       Date            : 2012-04-11
> >
> >         http://tools.ietf.org/html/draft-ietf-6man-rfc3484bis-02
> >
> > as Proposed Standard.  Substantive comments and statements of support
> > for advancing this document should be directed to the mailing list.
> > Editorial suggestions can be sent to the authors.  This last call will
> > end on April 26, 2012.
> >
> > Regards,
> > Ole Troan & Bob Hinden
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6 <at> ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely for the
> use of the individual or entity to which it is addressed. If you are not the
> intended recipient of this E-mail, you are hereby notified that any dissemination,
> distribution, copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be unlawful. If you have
> received this E-mail in error, please notify the sender immediately and
> permanently delete the original and any copy of this E-mail and any printout.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 <at> ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Dave Thaler | 4 May 2012 02:40
Picon
Favicon

RE: 3484bis and privacy addresses

I wrote in response to Ray Hunter:
> I take your comment as asking for a summary table in rfc 3484bis of
> system-wide config options.   That could be done as a purely editorial
> change, although if there's only 1 thing in the table it's less interesting.
> But if others in the WG think this would be helpful, then yes we can do that.

Turns out there were already 2 things so I've done this in -03.  

OLD:
	This specification optionally allows for the possibility of
	administrative configuration of policy (e.g., via manual
	configuration or a DHCP option such as that proposed in
	[I-D.ietf-6man-addr-select-opt]) that can override the default
	behavior of the algorithms.  The policy override takes the form of a
	configurable table that specifies precedence values and preferred
	source prefixes for destination prefixes.  If an implementation is
	not configurable, or if an implementation has not been configured,
	then the default policy table specified in this document SHOULD be
	used.

NEW:
	This specification optionally allows for the possibility of
	administrative configuration of policy (e.g., via manual
	configuration or a DHCP option such as that proposed in
	[I-D.ietf-6man-addr-select-opt]) that can override the default
	behavior of the algorithms.  The policy override consists of the
	following set of state, which SHOULD be configurable:

	o  Policy Table (Section 2.1): a table that specifies precedence
	   values and preferred source prefixes for destination prefixes.
	o  Automatic Row Additions flag (Section 2.1): a flag that specifies
	   whether the implementation may automatically add site-specific
	   rows for certain types of addresses.
	o  Privacy Preference flag (Section 5): a flag that specifies whether
	   temporary source addresses or stable source addresses are
	   preferred by default, when both types exist.

This is purely an editorial change.   The rest of Ray's comments apply
to I-D.ietf-6man-addr-select-opt, which is already informatively 
referenced in the above text.

-Dave

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
t.petch | 4 May 2012 09:47

Re: Options for draft-ietf-6man-uri-zoneid

Brian

To me, Option 3 is the clear, right way to go.

Percent escaping is the purist answer, fine for URI experts who deal with
percent escaping all the time.  Most of the world is completely comfortable with
URIs as long as they look like
www.example.com/user/sample.html
Some get confused even by the addition of http: and most would be completely
thrown by the appearance of a percent sign (even if they are always appearing on
the Internet Explorer address bar, which most people either do not look at or
have turned off).

I believe that the audience for this feature is widespread, not just limited to
URI experts.  IPv6 is horribly complicated, it will often go wrong, so I see
help desks asking users to key this in as a common use case.  In which case, you
need a simple to locate on the keyboard, simple to refer to in 'English',
character to separate the two fields.  %25 is not it.

Anything else would do but I think that underscore is the worst choice, because
it vanishes.
http://[fe80::a_en1
on my Microsoft MUA displays, underlined in blue, as
f e 8 0 : : a [space] e n 1
so that is what I know it is; except of course I am a URI expert so I know that
if it were really a space, the e n 1 would not be underlined in blue so there is
a invisible underline there!

tilde is nice, but too hard to find on the keyboard, so, of unreserved, that
leaves period or hyphen; I would go for hyphen.

--- Original Message -----
From: "Brian E Carpenter" <brian.e.carpenter <at> gmail.com>
To: "6man" <ipv6 <at> ietf.org>
Sent: Sunday, April 29, 2012 9:54 AM

> 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
> several years ago, but at that time the topic was simply dropped.
>
> This note summarises the main options. As a reminder, the problem to
> be solved is how to tell a browser which interface to use when sending
> packets to a literal link-local address. The reason for doing this is
> purely for diagnostic purposes, since the Zone ID that identifies an
> interface has no significance outside the sending host. For more details,
> see the two drafts mentioned above.
>
> What we have today: link local address with no Zone ID
>    http://[fe80::a]
>
> The user cannot select the outgoing interface if there is more than one.
>
> The obvious solution would be to use the RFC4007 syntax (for an
> example Zone ID of en1):
>
>    http://[fe80::a%en1]
>
> However, this is impossible because % is *always* an escape character in
> URI syntax [RFC3986]. There is no chance of the URI community accepting
> such a hack to the syntax, so it isn't an option for us.
>
> The available options are therefore
>
> 1) Leave the problem unsolved.
>
> This would mean that per-interface diagnostics would still have to be
> performed using ping or ping6
>
>    ping fe80::a%en1
>
> Advantage: works today.
>
> Disadvantage: less convenient than using a browswer.
>
> 2) Escaping the escape character as allowed by RFC 3986:
>
>    http://[fe80::a%25en1]
>
> Advantage: allows use of browser.
> Disadvantage: ugly and confusing, doesn't allow simple cut and paste.
>
> 3) With alternative separator such as _
>
>    http://[fe80::a_en1]
>
> Advantage: allows use of browser.
> Disadvantage: doesn't allow simple cut and paste.
>
> 4) With the "IPvFuture" syntax left open in RFC 3986:
>
>    http://[v6.fe80::a_en1]
>
> Advantage: allows use of browser.
> Disadvantage: ugly and redundant, doesn't allow simple cut and paste.
>
> Thus, the WG has to choose between options 1), 2), 3) and 4).
>
> Opinions welcome!
>
>     Brian Carpenter

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 7 comments |
headers
Ole Trøan | 4 May 2012 12:39
Favicon

Re: Options for draft-ietf-6man-uri-zoneid

> 1) Leave the problem unsolved.
> 
> This would mean that per-interface diagnostics would still have to be
> performed using ping or ping6
> 
>   ping fe80::a%en1
> 
> Advantage: works today.
> 
> Disadvantage: less convenient than using a browswer.
> 
> 2) Escaping the escape character as allowed by RFC 3986:
> 
>   http://[fe80::a%25en1]
> 
> Advantage: allows use of browser.
> Disadvantage: ugly and confusing, doesn't allow simple cut and paste.

if we went with option 2; considering that most browsers accept other inputs than URIs,
could the UI input be as today (fe80::a%en1) and the URI representation as (fe80::a%25en1)?

presumably also with other characters in the interface name escaped.
e.g. if I input "interface Dot11Radio0/0/0" in Chrome's address bar I get
"interface+Dot11Radio0%2F0%2F0"

cheers,
Ole

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 3 comments |
headers
mohamed.boucadair | 4 May 2012 14:50

draft-ietf-mboned-64-multicast-address-format

Dear all,
 
During the IETF LC for draft-ietf-mboned-64-multicast-address-format, Brian suggested to use the remaining flag instead of reserving ff3x:0:8000/33 (SSM) and ffxx:8000/17 (ASM) blocks. FYI, we have considered that approach in an early version of the document but it has been abandoned because of comments we received at that time. We recorded the rationale behind our design choice in:
 
We are seeking more feedback from 6man and mboned on the following:
 
(1) Should we maintain the current design choice
(2) Or adopt the suggestion from Brian?
 
FWIW, discussion related to this issue can be found here: http://www.ietf.org/mail-archive/web/mboned/current/msg01508.html.
 
Your help is appreciated.
 
Cheers,
Med
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 11 comments |
headers
Rajiv Asati (rajiva | 4 May 2012 15:29
Picon
Favicon

Re: Options for draft-ietf-6man-uri-zoneid

+1 for option 3 with hyphen. 

I like to be able to read the URI without having to put my glasses on.

Cheers,
Rajiv

Sent from my Phone

On May 4, 2012, at 3:50 AM, "t.petch" <ietfc <at> btconnect.com> wrote:

> Brian
> 
> To me, Option 3 is the clear, right way to go.
> 
> Percent escaping is the purist answer, fine for URI experts who deal with
> percent escaping all the time.  Most of the world is completely comfortable with
> URIs as long as they look like
> www.example.com/user/sample.html
> Some get confused even by the addition of http: and most would be completely
> thrown by the appearance of a percent sign (even if they are always appearing on
> the Internet Explorer address bar, which most people either do not look at or
> have turned off).
> 
> I believe that the audience for this feature is widespread, not just limited to
> URI experts.  IPv6 is horribly complicated, it will often go wrong, so I see
> help desks asking users to key this in as a common use case.  In which case, you
> need a simple to locate on the keyboard, simple to refer to in 'English',
> character to separate the two fields.  %25 is not it.
> 
> Anything else would do but I think that underscore is the worst choice, because
> it vanishes.
> http://[fe80::a_en1
> on my Microsoft MUA displays, underlined in blue, as
> f e 8 0 : : a [space] e n 1
> so that is what I know it is; except of course I am a URI expert so I know that
> if it were really a space, the e n 1 would not be underlined in blue so there is
> a invisible underline there!
> 
> tilde is nice, but too hard to find on the keyboard, so, of unreserved, that
> leaves period or hyphen; I would go for hyphen.
> 
> --- Original Message -----
> From: "Brian E Carpenter" <brian.e.carpenter <at> gmail.com>
> To: "6man" <ipv6 <at> ietf.org>
> Sent: Sunday, April 29, 2012 9:54 AM
> 
>> 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
>> several years ago, but at that time the topic was simply dropped.
>> 
>> This note summarises the main options. As a reminder, the problem to
>> be solved is how to tell a browser which interface to use when sending
>> packets to a literal link-local address. The reason for doing this is
>> purely for diagnostic purposes, since the Zone ID that identifies an
>> interface has no significance outside the sending host. For more details,
>> see the two drafts mentioned above.
>> 
>> What we have today: link local address with no Zone ID
>>   http://[fe80::a]
>> 
>> The user cannot select the outgoing interface if there is more than one.
>> 
>> The obvious solution would be to use the RFC4007 syntax (for an
>> example Zone ID of en1):
>> 
>>   http://[fe80::a%en1]
>> 
>> However, this is impossible because % is *always* an escape character in
>> URI syntax [RFC3986]. There is no chance of the URI community accepting
>> such a hack to the syntax, so it isn't an option for us.
>> 
>> The available options are therefore
>> 
>> 1) Leave the problem unsolved.
>> 
>> This would mean that per-interface diagnostics would still have to be
>> performed using ping or ping6
>> 
>>   ping fe80::a%en1
>> 
>> Advantage: works today.
>> 
>> Disadvantage: less convenient than using a browswer.
>> 
>> 2) Escaping the escape character as allowed by RFC 3986:
>> 
>>   http://[fe80::a%25en1]
>> 
>> Advantage: allows use of browser.
>> Disadvantage: ugly and confusing, doesn't allow simple cut and paste.
>> 
>> 3) With alternative separator such as _
>> 
>>   http://[fe80::a_en1]
>> 
>> Advantage: allows use of browser.
>> Disadvantage: doesn't allow simple cut and paste.
>> 
>> 4) With the "IPvFuture" syntax left open in RFC 3986:
>> 
>>   http://[v6.fe80::a_en1]
>> 
>> Advantage: allows use of browser.
>> Disadvantage: ugly and redundant, doesn't allow simple cut and paste.
>> 
>> Thus, the WG has to choose between options 1), 2), 3) and 4).
>> 
>> Opinions welcome!
>> 
>>    Brian Carpenter
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 <at> ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 6 comments |

Gmane