.
It's not my favourite outcome, but based on Dave Thaler's comment,
it's the one that gets my vote.
+1
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 http://www.jacobs
implementors may accept %en1 (when it is unambiguous) and
turn it into %25en1. (Many browsers already do this kind of thing
today for other characters that need escaping.)
I see no value in introducing a new separator.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
/2012 17:49, Juergen Schoenwaelder wrote:
On Sun, Jul 15, 2012 at 05:19:36PM +0100, Brian E Carpenter wrote:
... OK, as a result of Dave's comments, we now say:
Section 11 of RFC 4007 is updated to allow - as well as % as the
preceding delimiter of a ZoneID.
What we do *not* say
reading of this text was:
The canonical format for the zone index _in this typedef_ is
the numerical format as described in RFC 4007, Section 11.2.
That is the canonical applies to the YANG typedef, not to RFC 4007
(but we use the RFC 4007 SHOULD format as the canonical format.
/js
--
Juergen
a users' perspective pretty much a disaster.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 http://www.jacobs-university.de
On Fri, May 11, 2012 at 07:56:43AM +0100, Brian E Carpenter wrote:
On 2012-05-10 11:39, t.petch wrote:
Original Message -
From: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de
To: Brian E Carpenter brian.e.carpen...@gmail.com
Cc: 6man ipv6@ietf.org
Sent: Tuesday
in various tools and
interfaces and that this might at the end even cause changes to other
tools and specifications that currently are just fine with using % as
a separator. Perhaps I am overly anxious but only future will tell.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
not just by plain good old http and web
browsers, I think we will have to find and document a common solution
for this.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 http
are always consistent with IPvFuture. (But I might as
well be missing something.)
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 http://www.jacobs-university.de
allows 255 UTF-8 characters and I think it would
be nice to think a moment about how these things fit together.
PS: RFC 3493 only says there is a constant IF_NAMESIZE - so the socket
API does not really say what the interface name size limit really
is.
--
Juergen Schoenwaelder
need to think what to do about interface names that contain
characters not matching the unreserved production of RFC 3986. Perhaps
if all characters are digits, we can treat the value as an interface
number as a last resort.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
*15unreserved
and my understanding of unreserved is that it does not allow %
escaping. So the ZoneID production should likely be changed to
something like this:
ZoneID = *( unreserved / pct-encoded )
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587
are the wrong
procedure to question working group decisions. That said, let me add
that I support the decision documented in RFC 5952 (and which is also
codified in RFC 6021).
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 http://www.jacobs-university.de/
IETF IPv6 working group mailing list
.
For example, 2001:db8::0:1 is not acceptable, because the symbol ::
could have been used to produce a shorter representation 2001:db8::1.
I think this change makes it read better:
s/, and used/, and it MUST be used/
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49
.
This is a less invasive change (and I think the WG had previously some
concensus on this, but the WG chairs will know). But yes, the formally
correct procedure is likely the errata approach.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1
On Wed, Aug 04, 2010 at 08:44:46PM +0200, Fred Baker wrote:
On Aug 4, 2010, at 5:56 PM, Juergen Schoenwaelder wrote:
On Wed, Aug 04, 2010 at 05:34:39PM +0200, Fred Baker wrote:
I think this is a mis-use of AUTH48; the working group has
considered the draft and said what it wanted
of the motivations behind this work.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 http://www.jacobs-university.de
in many places in a
textual form where the options of automated search and comparison are
textual and conversion to a 128-bit binary number for comparison is
often not a realistic option. Section 3 of the ID discusses some
examples.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
), I might be OK with 2) if the
frequency of the introduction of new WKPs is very small.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 http://www.jacobs-university.de
not
matter how an address was generated when it comes to questions such as
ordering of addresses. I would prefer if the wording in this document
allows for the single representation approach taken in the above
mentioned document.
/js
--
Juergen Schoenwaelder Jacobs University Bremen
Pages : 14
Date : 2009-06-11
as a 6MAN Working Group document. Please state your opinion in favor of
or against adopting this document by August 15, 2009.
I am in favour.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587
what is already done in many
implementations.
+1
The NETMOD WG is currently adopting the same format as the canonical
representation of IPv6 addresses.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax
of the table
objects.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 http://www.jacobs-university.de
of a particular endpoint change
over time?
The udpEndpointInstance object is part of the INDEX. Since a row in
the udpEndpointTable represents a particular endpoint, I would say
this object like all other INDEX objects serves to identify an
endpoint.
/js
--
Juergen Schoenwaelder
On Mon, Jun 05, 2006 at 05:02:33PM -0700, Anders Persson wrote:
Juergen Schoenwaelder wrote:
On Mon, Jun 05, 2006 at 03:26:25PM -0700, Anders Persson wrote:
The udpEndpointInstance object is part of the INDEX. Since a row in
the udpEndpointTable represents a particular endpoint, I would say
would have to create
new tables...
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
IETF IPv6 working group mailing list
ipv6
ids and transport endpoints.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
IETF IPv6 working group mailing list
ipv6
of changes to APPENDIX A below (marked by ).
I support the addition of this clarification.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
unhappy.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
if
it makes the procedural aspects getting it written down within the IETF
more complex.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https
smicng. ;-)
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
are kept in the document, I think there should
be a clear warning attached about using them.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
the application code to work for both, IPv4
mapped address format is very useful tool.
On those other socket APIs, does code which uses two sockets work
or not?
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen
even more reasons to treat the host portion of URIs in
special ways.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
IETF IPv6
-fielding-uri-rfc2396bis-07.txt
allows %xx notation in host part.
Does someone know the actual motivation for this change? Which problem
were they trying to solve by allowing %xx notation in the host part?
/js
--
Juergen Schoenwaelder International University Bremen
http
and which sends
a properly constructed URI including a zone ID to a box for consumption
on that box.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
might be different.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
IETF IPv6 working group mailing list
[EMAIL PROTECTED
, it is widely implemented and the code is out
there in customer hands.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
IETF IPv6
this is worth the effort it takes? So far, I have not
seen a real-world report that zone ids are indeed needed in URIs.
This _might_ come up in the future - but do we really expect to
change all the already existing code for the reason that the %
does not fit easily into URIs?
/js
--
Juergen
to have a wildcard value which says do not match this
header. The IPv6FlowLabelOrAny TC is exactly for this purpose.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
. And this is the first time I can remember
(and that I could find in my mailing list archive) that a change
to generally allow zero-length InetAddress values has been proposed.
Unless I hear a strong move to change the rule above, I actually prefer
to stay with what we have.
/js
--
Juergen
inetCidrRoutePfxLen MUST be
equal to x. If not, then the index pair is not
consistent and an inconsistentName error must be
returned on SET or CREATE requests.
This text is clearly an improvement over what has been there before.
/js
--
Juergen Schoenwaelder
:
[...]
And, if I remember the discussion correctly, the consensus was we
should mandate zero as the default. So, I'd like to propose the
following changes:
I am happy with these changes.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box
fit into an OID
subidentifier.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
IETF IPv6 working group mailing list
[EMAIL
that just 0 was removed
from the set of possible values.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
IETF IPv6 working
to the objects in question that use the
InetPrefixLength TC?
c) Do both?
I think I prefer a) at the moment.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
: ipAddressRowStatus of type RowStatus.
3) Maybe changing the conformance statements to allow the
optionality of the writable aspect of it.
You probably also want to have a StorageType column for this.
/js
--
Juergen Schoenwaelder International University Bremen
http
this up by at
least saying the default zone SHOULD be identified by the zone index 0.
/js
--
Juergen Schoenwaelder International University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
50 matches
Mail list logo
