Re: Registration of media type application/calendar+xml

[Tony Finch]

On 10 Sep 2010, at 06:09, Keith Moore  wrote:
> 
> If you have a beef with the iCalendar data model, feel free to try to come up 
> with a better one.

Funny you should say that :-)
http://fanf.livejournal.com/104586.html

Tony.
--
f.anthony.n.finchhttp://dotat.at/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Julian Reschke]

On 10.09.2010 04:51, Keith Moore wrote:

...
Provided, of course, that HTTP-based calendar protocols are being used.   But 
currently, all of the iCalendar content I receive is over email.
...


For me, the opposite is true.

Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Alexandru Petrescu]

Le 10/09/2010 11:30, Hesham Soliman a écrit :




On 9/09/10 4:28 PM, "Alexandru
Petrescu" wrote:


Le 09/09/2010 08:01, Hesham Soliman a écrit :




On 9/09/10 3:54 PM, "Wassim Haddad"
wrote:


On Sep 8, 2010, at 7:58 AM, Alexandru Petrescu wrote:


I agree mainly with the document draft-ietf-mext-nemo-pd.

It is good and needed to dynamically assign a Mobile Network
 Prefix to the NEMO-enabled Mobile Router.

However, here are a couple of missing points.

One missing point is about how will the Mobile Router
configure its default route on the home link?  I thought
Prefix Delegation would bring DHCP in the picture and would
allow MR to synthesize a default route even though RAs are
absent.  But I now realize that a DHCPv6-PD implementation
(and std?) does not allow a router (MR) to synthesize its
default route (neither RA does, nor DHCPv6-nonPD does).


=>   I think the MR can easily act as a host on its egress
interface and configure its default/next hop router that way. Of
course the other alternative is to use routing protocols, but I
think using ND should be sufficient.


Hesham - when at home, the MR acts  as a router (ip_forward==1,
join all-routers group), as such ND is insufficient to obtain the
default route - it's a Router.

When at home, and using DHCPv-PD, the MR also acquires its Home
Address with DHCPv6.  If so, then it doesn't use SLAAC to
auto-configure neither a Home Address nor a default route.

In implementation it is of course possible to dynamically change MR
behaviour from Host to Router: be at home, first act as host
(fwd==0) to acquire the Home Address and default route, then set
fwd=1 and use DHCPv6-PD to acquire a prefix (but not the Home
Address) and take advantage of the default route acquired
previously as a Host.  This is one way of solving the issue.


=>  Exactly.

However it is not specified.

=>  Who cares, specify it in your product description. The IETF
doesn't specify how to build products.


Hmm... to me it is a very IETF sensitive issue the Router vs Host.  For 
example, an ND spec says distinctively what a Host and what a Router 
does, e.g. a Host does not respond to Router Solicitation.


In this same way a Router should dynamically be able to obtain a default
route, in addition to a Host doing so.

The products sold are neither Hosts nor Routers - they're BFRs, servers,
desktops, tablets, laptops.


If you want to solve this with protocols then use routing protocols.
Of course you need to solve the security issues when the MR moves.


But SLAAC (what you call ND) is not a routing protocol yet does deliver
a default route, only to Hosts.  DHCPv6 is not a routing protocol either
but does not deliver a default route neither to Hosts nor to Routers.

(I am not clear whether the DHCPv6 spec forbids delivery of a default
 route; or allows; I have to check; the implementation does not.)


I am not

sure how clean is it anyways to disregard that 'M' bit of RA
anyways.

The alternative to using routing protocols (OSPF?) to communicate a
default route to the MR - I am not sure how this could work, never
seen it in practice.


=>  For  a good reason! You need to work out trust across domains.


Probably...

Alex



Hesham



Alex




Hesham















___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Alexandru Petrescu]

Le 10/09/2010 11:48, Hesham Soliman a écrit :





=>   Who cares, specify it in your product description. The IETF
 doesn't specify how to build products.


Hmm... to me it is a very IETF sensitive issue the Router vs Host.
For example, an ND spec says distinctively what a Host and what a
Router does, e.g. a Host does not respond to Router Solicitation.


=>  Yes and it does so on a per-interface basis, not on a
per-machine basis.


Yes, and the Mobile Router is a Router on its egress interface when
connected at home, as per spec.  It is that interface that needs a
default route automatically configured.

Alex



Hesham



In this same way a Router should dynamically be able to obtain a
default route, in addition to a Host doing so.

The products sold are neither Hosts nor Routers - they're BFRs,
servers, desktops, tablets, laptops.


If you want to solve this with protocols then use routing
protocols. Of course you need to solve the security issues when
the MR moves.


But SLAAC (what you call ND) is not a routing protocol yet does
deliver a default route, only to Hosts.  DHCPv6 is not a routing
protocol either but does not deliver a default route neither to
Hosts nor to Routers.

(I am not clear whether the DHCPv6 spec forbids delivery of a
default route; or allows; I have to check; the implementation does
not.)


I am not

sure how clean is it anyways to disregard that 'M' bit of RA
anyways.

The alternative to using routing protocols (OSPF?) to
communicate a default route to the MR - I am not sure how this
could work, never seen it in practice.


=>   For  a good reason! You need to work out trust across
domains.


Probably...

Alex



Hesham



Alex




Hesham






















___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Julian Reschke]

On 10.09.2010 07:09, Keith Moore wrote:

On Sep 10, 2010, at 12:34 AM, Phillip Hallam-Baker wrote:
...

If you want to have a system in which 95% of your data structures are
in XML you probably don't want to have to introduce a separate syntax
and you most certainly do not want to deal with a separate data model
for dealing with calendaring.


It's not at all clear that trying to coerce 95% of the data models in
your system to be compatible with XML is a worthwhile goal. The XML data
model is tortured. Trying to impose it on network protocols should be
regarded as an act of violence.
...


That's *far* from clear. Could you elaborate in the context of 
calendaring? As far as I can tell, the torture is more about having to 
parse what we have today.



At any rate, this proposal doesn't change the iCalendar data model - it
just makes it harder to use. If you have a beef with the iCalendar data
model, feel free to try to come up with a better one.


I disagree that it makes it harder to use, *unless* somebody wants to 
require support for this alternate format.


On the other hand, having an agreed-upon mapping from/to XML will make 
it easier for many developers. Well, at least those who don't have a 
problem with XML :-)



The iCalendar format represents a 1990s style approach to the problem.
There is no real separation of syntax from the data model. Software
developed in that manner is notoriously difficult to get right for the
reasons that Keith describes.


XML has lots of problems of its own. I recently had to review a
specification that referenced WS-i and WS-security and about a couple of
thousand other pages of useless crap that went with it. All for the sake
of being able to transmit about six meaningful name-value pairs from a
client to a server. It was completely ridiculous.


Yes, WS-* sucks. Big news.


I'm no fan of the iCalendar format, nor the vCard and vCalendar formats
that preceded it. But for all of its purported generality (and perhaps
because of it) XML has turned out to be no better, and in many ways
worse. It's amazing how hard people will work to make a simple idea
complex, especially when the simple idea has become a bandwagon, or (in
this case) a religion.

In principle, it would make sense for things to have a uniform syntax.
But XML gets this wrong in several different ways. The most obvious is
that XML data structures don't map well onto data structures supported
by programming languages. That's probably because SGML wasn't designed
to do that - it was designed to mark up text. Another problem is that
XML confuses typing and naming. Another problem (especially when mapping
other structures to/from XML) is that the distinction between parameters
and sub-elements is pretty much arbitrary.


That may all be true. But strangely enough, there doesn't seem to be 
much energy to come up with something better *and* get people to agree 
on that.


Turning a type registration request into an to-XML-or-not-to thread 
doesn't appear to be productive to me.



XML is a substantial overhead if you are dealing with a single
protocol but when you are dealing with multiple protocols the benefits
are substantial and allow something like 70% of your coding effort to
be pushed onto the platform layer. That means that you have 70% less
new code and new code paths to contend with.


If your programmer is spending 70% of his coding time dealing with a
presentation layer, even one as convoluted as iCalendar, you should fire
him. It's not like regular expression parsers are hard to come by these
days. Nor are libraries that can parse standard formats hard to come by.


Can iCalendar be parsed reliably with regexps? (just asking).


Another of the big problems with the XML religion is that its adherents
have the mistaken impression that defining the syntax is most of the
work of defining a protocol - so that once you decide to use XML, most
of the work is done. Apparently, semantics don't matter much.


Another big problem with the anti-XML religion is that its adherents 
like to over-generalize, such as deducing badness of XML from 
WS-deathstar encounters.


Yes, there's lots of bad use of XML. The same can be said about other 
formats as well.



...
It enforces consistency in syntax. Taken by itself, that's a good thing.
But when you parse XML you don't get a very usable data structure. You
get a mess. And once you do the work of transforming that data structure
into an effective internal representation, you've negated whatever
advantage you might have found in not having to have written a
parser/generator for it. You haven't solved the problem of needing a
parser and generator - you've just moved it. Instead of parsing text
you're parsing a DOM structure. You've added an extra layer or two for
no benefit.


The benefit is that the XML parser already has taken care of many things 
people get wrong all the time; character encodings, escaping, line 
endings etc.



You're essentially arguing the syn

Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Alexandru Petrescu]

Le 10/09/2010 11:58, Hesham Soliman a écrit :




On 10/09/10 7:55 PM, "Alexandru
Petrescu" wrote:


Le 10/09/2010 11:48, Hesham Soliman a écrit :





=>Who cares, specify it in your product description. The
 IETF doesn't specify how to build products.


Hmm... to me it is a very IETF sensitive issue the Router vs
Host. For example, an ND spec says distinctively what a Host
and what a Router does, e.g. a Host does not respond to Router
 Solicitation.


=>   Yes and it does so on a per-interface basis, not on a
per-machine basis.


Yes, and the Mobile Router is a Router on its egress interface
when connected at home, as per spec.  It is that interface that
needs a default route automatically configured.


=>  Ok, so you're happy with it being half host half router when it's
away from home?


When it is away from home it is fully a Host on the egress interface.
When at home fully Router on same.  I am happy with it this way.


If so then let it do the same at home. Otherwise, I don't know how
you want to fix this in this WG.


It would mean to specify it to be a at home, be first a Host (get
default route) then change and become a Router, but still at home.

This behaviour could be set in the DHCPv6-PD-NEMO draft, being under
discussion now.

Alex



Hesham






___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Keith Moore]

On Sep 10, 2010, at 6:11 AM, Julian Reschke wrote:

> On 10.09.2010 07:09, Keith Moore wrote:
>> On Sep 10, 2010, at 12:34 AM, Phillip Hallam-Baker wrote:
>> ...
>>> If you want to have a system in which 95% of your data structures are
>>> in XML you probably don't want to have to introduce a separate syntax
>>> and you most certainly do not want to deal with a separate data model
>>> for dealing with calendaring.
>> 
>> It's not at all clear that trying to coerce 95% of the data models in
>> your system to be compatible with XML is a worthwhile goal. The XML data
>> model is tortured. Trying to impose it on network protocols should be
>> regarded as an act of violence.
>> ...
> 
> That's *far* from clear. Could you elaborate in the context of calendaring?

Sigh.  Do I have to write the code to parse the XML and do something with it to 
show that it's tortured?

> As far as I can tell, the torture is more about having to parse what we have 
> today.

Granted, iCalender is ugly.  But you still have to parse it if you want to 
interoperate with the installed base. 

> Yes, WS-* sucks. Big news.

I mention it because it's a good example of the "everything should be XML" 
disease, and a "2010s style" approach to the problem.  Things were better in 
the 1990s.

>> In principle, it would make sense for things to have a uniform syntax.
>> But XML gets this wrong in several different ways. The most obvious is
>> that XML data structures don't map well onto data structures supported
>> by programming languages. That's probably because SGML wasn't designed
>> to do that - it was designed to mark up text. Another problem is that
>> XML confuses typing and naming. Another problem (especially when mapping
>> other structures to/from XML) is that the distinction between parameters
>> and sub-elements is pretty much arbitrary.
> 
> That may all be true. But strangely enough, there doesn't seem to be much 
> energy to come up with something better *and* get people to agree on that.

Give it time.  Of course, now that there is all of this XML to displace, it's 
hard for something new to get traction.

> Turning a type registration request into an to-XML-or-not-to thread doesn't 
> appear to be productive to me.

Fortunately, we don't need to.  iCalendar already exists, and is not XML.  
There's no demonstrated need for a new type, whether in XML or any other syntax.

> Can iCalendar be parsed reliably with regexps? (just asking).

WIthout actually doing the exercise, yes I think so.  I don't recall much (if 
any) recursion in iCalendar.  Of course the real question is how easy it is to 
translate ABNF into code that uses regexps.  

(I do think it's ironic that we went to all of this trouble way back in the 
DRUMS WG to produce a new version of ABNF that would allow the syntax of 
something to be completely specified - without resorting to comments - and 
machine parseable.   And then we went to the trouble to rewrite a number of 
protocols using the new ABNF, accepting the pain and the possibility to 
introduce errors.   And now that we have it, we're not using it to generate 
parsers, and people are claiming that they need to use XML instead.  I suppose 
the one thing that XML adds here is that you don't have to design an internal 
data structure.  You can use the one that generates naturally from the XML even 
though it's likely to be very awkward to use.)

>> Another of the big problems with the XML religion is that its adherents
>> have the mistaken impression that defining the syntax is most of the
>> work of defining a protocol - so that once you decide to use XML, most
>> of the work is done. Apparently, semantics don't matter much.
> 
> Another big problem with the anti-XML religion is that its adherents like to 
> over-generalize, such as deducing badness of XML from WS-deathstar encounters.

Fair enough - but I do think it's a good example of what happens when people 
insist that everything be XML.

> Yes, there's lots of bad use of XML. The same can be said about other formats 
> as well.

And I'm not arguing that iCalendar is a well-designed syntax.   If we were 
building it today, I'd be okay with using XML (not because I like XML, but 
because it would be politically expedient, and the chances are good than an ad 
hoc format designed by a WG today would be no better).   My objection is to 
having two calendar formats.

> The benefit is that the XML parser already has taken care of many things 
> people get wrong all the time; character encodings, escaping, line endings 
> etc.

Yes, but you can get some of those things wrong (e.g. character encodings, and 
other differences between internal/external representation) internally to your 
program.

>> You're essentially arguing the syntax by which data is represented on
>> the wire - the presentation layer - should constrain how data is
>> represented internally in a system. And then you're arguing that the
>> particular constraints imposed by XML are appropria

Re: The Evils of Informational RFC's

[Jari Arkko]

I do think informational RFCs (both IETF and non-IETF) are valuable.

I would suggest though that their value is mostly NOT about ease of 
access, archival, those great ASCII graphics, or any other practical 
matter. The value is in our assessment of them being worthy of being 
published as RFCs. (Our = the IETF community, IESG and other reviews, 
RFC Editor board decisions, etc) I generally treat all information as 
suspect, even full standard RFCs (horror!) but I still think that across 
a number of different information sources even a vendor's protocol spec 
as an independent submission is pretty reliable.


So yes, lets keep on publishing informational, experimental, and 
individual and independent submission RFCs. They are not the primary 
source of technical information in Internet technology, but for me at 
least they do provide a lot of value.


Sam: about the binding Informational documents. I also do recognize that 
we sometimes make choices, say, about architectures or requirements and 
that we should stick with those decisions in future work. However, I 
would like to make two comments on this. First, many decisions of this 
sort are soft rather than hard. As an example, we often compromise on a 
requirement in order to reach a feasible solution. I'm not sure we want 
to bind ourselves to decisions of this type in any formal sense. Second, 
I think it is easier to think of the bindingness in terms of the history 
of the document and the practical situation than as a binary attribute 
of the document class.


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Keith Moore]

On Sep 10, 2010, at 3:41 AM, Tony Finch wrote:

> On 10 Sep 2010, at 06:09, Keith Moore  wrote:
>> 
>> If you have a beef with the iCalendar data model, feel free to try to come 
>> up with a better one.
> 
> Funny you should say that :-)
> http://fanf.livejournal.com/104586.html

See also http://network-heretics.com/blog/?p=42

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Tony,

--On September 10, 2010 8:41:05 AM +0100 Tony Finch  wrote:


If you have a beef with the iCalendar data model, feel free to try to
come up with a better one.


Funny you should say that :-)
http://fanf.livejournal.com/104586.html


That is a beef about timezones - one piece of iCalendar, but my no means 
all of it.


I disagree with your suggestion of using a location to represent a timezone 
- there are a number of reasons why that won't work - not least that many 
events often do not have a physical location associated with them.


That said work is going on to move to a "timezone by reference" rather than 
"timezone by value" model for iCalendar. There are many driving forces 
behind that, including several of the points you mention, plus the fact 
that often times the timezone definition included in iCalendar data is 
larger than (character-wise) then the actual event information, wasting 
bandwidth.


To that end several options are being proposed. We have already posted a 
draft for a generic timezone service 
() - a 
server that can be queried for timezone definitions based on standard IDs 
(Olson identifiers). This allows clients and servers to get timely updates 
to timezone information (rather than having to wait for the next OS 
upgrade). We are working on defining how "timezone by reference" will work 
with the CalDAV calendar access protocol (RFC4791). Since that uses HTTP, 
simple client/server negotiation options exist to facilitate that.


Note that the timezone service is not intended to just be used by iCalendar 
related tools - but we expect/hope that any device that needs to cache 
timezone definitions (e.g. unix zoneinfo data) can also make use of that.


Best place to continue this particular aspect of the discussion would be 
the ietf-calsify WG mailing list.


--
Cyrus Daboo

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Julian,

--On September 10, 2010 12:11:27 PM +0200 Julian Reschke 
 wrote:



If your programmer is spending 70% of his coding time dealing with a
presentation layer, even one as convoluted as iCalendar, you should fire
him. It's not like regular expression parsers are hard to come by these
days. Nor are libraries that can parse standard formats hard to come by.


Can iCalendar be parsed reliably with regexps? (just asking).


The Python vobject library that we use in our CalDAV server 
(http://calendarserver.org) does use regular expressions for parsing entire 
lines (after applying line "unfolding" of the overall text object), and 
then parsing out pieces of those. That is used for both iCalendar and vCard.


--
Cyrus Daboo

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Keith,

--On September 10, 2010 1:40:16 AM -0400 Keith Moore  
wrote:



But here's the acid test.  If you can define a mapping from iCalendar to
XML that doesn't require any string constants to describe it (other than
for iCalendar keywords that imply nesting, and separators that are used
in a regular fashion in iCalendar), and if you can define the inverse
mapping from XML to iCalendar without naming more than a couple of
specific element or parameter names - then I'll concede that the mapping
will probably continue to work in the face of extensions to the iCalendar
data model.   Otherwise, I'm highly dubious.


That is precisely the goal of draft-daboo-et-al-icalendar-in-xml. iCalendar 
components, properties, parameters and values all map to XML in a 
consistent manner with no need to "special case" based on type or value. 
New components, properties, parameters, values, either registered with IANA 
or using X- prefixes map in exactly the same way.


Conversion to/from XML is trivial - I have coded at least one half of that 
and I know others who have done both ways.It should also be easy to put 
together an XSLT to go from XML to iCalendar - with the only possible 
difficulty being having to apply escaping and line folding as required by 
iCalendar.


--
Cyrus Daboo

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Keith Moore]

On Sep 10, 2010, at 9:56 AM, Cyrus Daboo wrote:

> Hi Keith,
> 
> --On September 10, 2010 1:40:16 AM -0400 Keith Moore  wrote:
> 
>> But here's the acid test.  If you can define a mapping from iCalendar to
>> XML that doesn't require any string constants to describe it (other than
>> for iCalendar keywords that imply nesting, and separators that are used
>> in a regular fashion in iCalendar), and if you can define the inverse
>> mapping from XML to iCalendar without naming more than a couple of
>> specific element or parameter names - then I'll concede that the mapping
>> will probably continue to work in the face of extensions to the iCalendar
>> data model.   Otherwise, I'm highly dubious.
> 
> That is precisely the goal of draft-daboo-et-al-icalendar-in-xml. iCalendar 
> components, properties, parameters and values all map to XML in a consistent 
> manner with no need to "special case" based on type or value. 

But you're not doing that in the draft.  You explicitly list every keyword.  
Every time a new component, property, parameter, etc is added to iCalendar, the 
mapping code will have to change also.  The trick is to be able to translate 
between formats, with no changes to the code needed even when the format is 
extended.

> Conversion to/from XML is trivial - I have coded at least one half of that 
> and I know others who have done both ways.It should also be easy to put 
> together an XSLT to go from XML to iCalendar - with the only possible 
> difficulty being having to apply escaping and line folding as required by 
> iCalendar.

That would be great, again provided you don't have to explicitly list every 
keyword.  It still wouldn't convince me that XML iCalendar is sufficiently 
valuable to be worth the degraded interoperability.  But if you're going to 
have two formats, being able to automatically convert between them is the best 
way to do that.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Keith,

--On September 10, 2010 10:09:11 AM -0400 Keith Moore  
wrote:



That is precisely the goal of draft-daboo-et-al-icalendar-in-xml.
iCalendar components, properties, parameters and values all map to XML
in a consistent manner with no need to "special case" based on type or
value.


But you're not doing that in the draft.  You explicitly list every
keyword.  Every time a new component, property, parameter, etc is added
to iCalendar, the mapping code will have to change also.  The trick is to
be able to translate between formats, with no changes to the code needed
even when the format is extended.


Fair enough. We can adjust e.g. Section 3.7 that talks about only X- 
extensions to also refer to any new iCalendar data objects. The basic 
premise being that new iCalendar data object names map directly to an XML 
element name. After each table in the previous sections we can add a 
reference to section 3.7 with a statement that that is how new items will 
be handled.



Conversion to/from XML is trivial - I have coded at least one half of
that and I know others who have done both ways.It should also be easy to
put together an XSLT to go from XML to iCalendar - with the only
possible difficulty being having to apply escaping and line folding as
required by iCalendar.


That would be great, again provided you don't have to explicitly list
every keyword.  It still wouldn't convince me that XML iCalendar is
sufficiently valuable to be worth the degraded interoperability.  But if
you're going to have two formats, being able to automatically convert
between them is the best way to do that.


It has always been our intent to have a 1-to-1 mapping between the two. We 
in fact went out of our way to ensure that the XML schema would not 
restrict in anyway what could be done with new iCalendar data objects.


--
Cyrus Daboo

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Alexandru Petrescu]

Le 10/09/2010 14:12, Hesham Soliman a écrit :






When it is away from home it is fully a Host on the egress
interface. When at home fully Router on same.  I am happy with it
this way.



=>  Ok that doesn't make any sense to me.


Well, let me rephrase as the RFC text puts it: when the MR is at home it
joins the all-routers multicast address, otherwise it joins the
all-hosts address.  ND spec says similar.  Similarly, when MR at home it
can send RAs on the egress, if away it MUST NOT send RAs on it.  It must
always send RAs on the ingress.  This is to make sure MR doesn't break
the Internet routing.

Does this sound better?


If so then let it do the same at home. Otherwise, I don't know
how you want to fix this in this WG.


It would mean to specify it to be a at home, be first a Host (get
default route) then change and become a Router, but still at home.


=>  Ditto.


Let me phrase otherwise.

Current DHCPv6-PD-NEMO text draft-ietf-mext-nemo-pd-06 says:

3.2. Exchanging DHCPv6 messages when MR is at home


When the MR is on its home link, the HA uses the home link to
exchange DHCPv6PD messages with the MR (Figure 3).


It should say: "when the MR is on its homelink, it can obtain an IPv6
address and a default route with SLAAC (if it acts as a Host), or simply
an IPv6 address and no default route, with DHCPv6; then, the HA uses the
home link to exchange DHCPv6PD..."

And in this section:

3.5. Other DHCPv6 functions


The DHCPv6 messages exchanged between the MR and the HA MAY also be
used for other DHCPv6 functions in addition to DHCPv6PD.  For
example, the HA MAY assign global addresses to the MR and MAY pass
other configuration information such as a list of available  DNS
recursive name servers [RFC3646] to the MR using the same DHCPv6
messages as used for DHCPV6PD.


It should say: "neither DHCPv6-PD nor SLAAC allow MR to autoconfigure a
default route".  Is this better?

Do you think there's no need to autoconfigure a default route on the MR
at home?

Do you think there's no problem in the fact that RFC forbids MR to
autoconfigure a default route while connected at home?

Do you think there's no problem in the fact that SLAAC and DHCPv6-PD
implementations dont offer a default route to MR at home?

Do you think nothing should be done at IETF about default route,
DHCPv6-PD and NEMOv6 MR at home?

Alex

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Keith,

--On September 9, 2010 10:51:10 PM -0400 Keith Moore  
wrote:



An XML representation for iCalendar is vital if we are to keep iCalendar
relevant in the web-based world. The drive for this work comes from a
number of areas - in particular the smart grid effort sponsored by NIST
will make use of this as part of the standards suite they are defining.


Somebody needs to talk some sense into those people.  Defining another
calendar format will only harm interoperability.  It doesn't save any
calendar implementation from needing to implement another parser, because
if it wants to interoperate with existing products or be able to read old
events it's still going to have to support iCalendar and probably
vCalendar also.  So what's the _technical_ (not political) benefit from
doing this?


First of all look at the mess we have got into with contacts (see recent 
discussion on the vcarddav WG mailing list). There we now have vCard, PoCo, 
OpenSocial and some new thing the OMA is doing (and their are lots of 
private apis too). Yet vCard has been around for a long time - why didn't 
those other folks just use that or at least propose fixes or extension to 
vcard that would satisfy their issues? Well, certainly in the case of PoCo 
one clear requirement was for a simple web/browser based solution - so they 
designed JSON and XML representations.


The same mess could happen to iCalendar too. In fact there are already lots 
of examples of "private" apis using XML to represent calendar data, see 
e.g. Google GDATA. Plus I know of some public event services that uses 
their own custom XML format for event publishers to submit calendar data to 
them. In fact the initial impetus for this work did come from one such 
public events company that really wanted to use iCalendar rather than some 
home grown solution, but really wanted that as XML. Sure you can argue that 
they should be made to parse iCalendar format, but why should they have to 
write their own new parser when they already have reliable, efficient XML 
processing available.


Frankly the important thing here is the semantics of the iCalendar model, 
not the syntax. I want developers to only have to concentrate on getting 
the semantics right without worry too much about the syntax.


Now I can understand your concern about poor interoperability when it comes 
to having the two data formats. I think for the HTTP-based world (CalDAV, 
iSchedule, web-services) this is really not a big deal given the content 
negotiation options. For something like iMIP (iCalendar in email) it is a 
much bigger problem. Speaking for myself only, and not my co-authors, I 
think I would be OK with adding a statement that iMIP messages SHOULD NOT 
use the application/calendar+xml format, or at the very least require both 
text/calendar and application/calendar+xml in e.g. a multipart/alternative 
(though I would worry that the later would cause existing clients problems, 
and lead to message bloat).



IETF's job is to provide technical leadership, not to follow bad advice.
Instead of caving into them, what we need to do is publish a draft called
"Translating Everything into XML Considered Harmful".


Ah, yes. I seem to recall something similar for the use of HTTP - perhaps 
the author of RFC 3205 would like to author this new document too :-)



--
Cyrus Daboo

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Julian Reschke]

On 10.09.2010 16:45, Cyrus Daboo wrote:

...

IETF's job is to provide technical leadership, not to follow bad advice.
Instead of caving into them, what we need to do is publish a draft called
"Translating Everything into XML Considered Harmful".


Ah, yes. I seem to recall something similar for the use of HTTP -
perhaps the author of RFC 3205 would like to author this new document
too :-)
...


In which case I'd be tempted to follow up with

"Inventing unnecessary new protocols, URI schemes and media types 
considered harmful as well - find a good balance, please"


:-)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[ned+ietf]

> On Sep 9, 2010, at 11:38 PM, Ned Freed wrote:

> >> This was a bad idea when it was first proposed (if I recall correctly) 
> >> around
> >> ten years ago, and it's still a bad idea.
> >
> > I strongly disagree.
> >
> >> Whenever you define an alternate representation of something, there will
> >> inevitably be skew between the original representation and the alternate
> >> representation.
> >
> > This is demonstrably false. The Sieve in XML representation specified in RFC
> > 5784 provides a counterexample - the way the format and mapping is defined,
> > there's no way to represent anything in the XML variant that cannot be
> > represent in the regular variant, and vice versa.

> RFC 5784 might well be a valiant effort toward that.  But it has only been
> out a few months, so I think the jury is still out as to how well it works in
> practice.

I'm still not hearing specifics as to how such a failure can occur, either
in the Sieve XML mapping or the iCal one.

Like most engineering problems, the devil is in the details, which aren't
addressed in any useful fashion by sweeping pronouncements about what
should or should not be attempted.

A mapping to and from XML can be done well or done badly. A good mapping
doesn't require schema and mapping tool changes to accomodate extensions, a bad
mapping does.

Let's look at a specific example. An 'fileinto "foo"' action in Sieve is mapped
by RFC 5784 to XML of the form:

foo

Suppose we had chosen;

foo

instead. Or maybe:

   

Both of these mappings are much simpler and easier to read, but they have a
major failing: The former requires a schema change in order to add new actions,
and the latter requires a schema change to accomodate any sort of extension to
fileinto. By using XML elements to represent the syntactic structure of Sieve
only, we create a situation where only a change to the fundamental syntax of
Sieve - something the base specification specifically prohibits extensions from
doing - is capable of forcing a change to the schema.

iCal has a similar core syntax to Sieve that extensions have to fit into and
cannot change. It follows that as long as that's all you try and represent
using XML elements, extensions will not necessitate a schema change and it
should be possible to write tools to perform the mapping that don't need to  be
updated when extensions are defined.

Unfortunately, now that I've had a chance to look at
draft-daboo-et-al-icalendar-in-xml-06.txt a little more, I find that it doesn't
do this well. For example, instead of mapping a property like dtstamp to
something like:


  20080205T191224Z


it maps it to:

   20080205T191224Z

This means that additional properties will necessitate a schema update. Not
good, and I believe this needs to be fixed.

> I also think it helps that RFC 5784 specifically says it's not intended as an
> alternate storage format for Sieve.  I can certainly see some utility in being
> able to use XML tools to manipulate things not originally written in XML.

It helps in the sense that it makes it clear who needs to support the alternate
format and who doesn't. But it has no effect at all on the issue of  how the
mapping accomodates extensions.

> But here's the acid test.  If you can define a mapping from iCalendar to XML
> that doesn't require any string constants to describe it (other than for
> iCalendar keywords that imply nesting, and separators that are used in a
> regular fashion in iCalendar), and if you can define the inverse mapping from
> XML to iCalendar without naming more than a couple of specific element or
> parameter names - then I'll concede that the mapping will probably continue to
> work in the face of extensions to the iCalendar data model.   Otherwise, I'm
> highly dubious.

I agree that this is what's needed. I don't think it's that difficult to do
though. And I don't think it is difficult to evaluate whether or not that goal
has been reached: All you have to do is look at the extensibility model, and
make sure that anything that conforms to the extensibility model isn't going to
require a schema change.

> Even then, this would not address the degraded interoperability resulting
> from the need to have multiple formats.

It's just not this simple. The loss in interoperability may be made up for by
the increase in accessibility by a different and very powerful set of tools.

> > I have only done a cursory review of iCalendar in XML specification, but I
> > believe it covers this issue adequately, and according to the document, it
> > clearly intends to define a format that fully support round trips between 
> > the
> > representations. If you believe it does not, it is up to you to provide
> > specifics of how it does not, rather than asserting there's a problem 
> > without
> > any actual evidence.

> I disagree, because there are interoperability problems resulting from the
> introduction of an alternate format even if the mappings remain invertable in
> the p

Re: Revised IAOC Administrative Procedures draft

[Bob Hinden]

Hi,

To date, I have not seen any comments.  The IAOC is putting this on it's agenda 
for our call next week.

Bob


On Aug 12, 2010, at 5:56 PM, Bob Hinden wrote:

> The IAOC solicits feedback on the revised Administrative Procedures draft 
> that is attached.
> 
> An early draft was sent to the community for comment on 28 May 2010.  Many 
> comments received were about how this relates to BCP101, if the IAOC was 
> changing BCP101, creating new rules, or clarifying areas where BCP101 was not 
> clear.  The attached draft should clarify these comments. 
> 
> In most cases, it includes the relevant BCP101 text and then describes how 
> the IAOC is implementing this.  There are a few cases where BCP101 does not 
> provide specific guidance.  In these cases the Administrative Procedures 
> describes what the IAOC is doing as BCP101 requires.
> 
> The first paragraph of the Administrative Procedures states:
> 
>   RFC 4071 (BCP 101) is the governing authority for IASA, the IAOC and
>   the IAD. It contains clear direction and guidance, but not all the
>   details required for the day-to-day operation of the IETF
>   Administrative Support Activity. BCP 101 section 3.4 specifically
>   tasks the IAOC to decide the details about its decision-making rules
>   and making them public. These Procedures are in response to that
>   requirement, and are further intended to provide clarity for the IAOC
>   and IAD in the execution of operational responsibilities. Further,
>   these procedures are not intended to change BCP 101; that would
>   require another BCP in accordance with section 2.4.
> 
> We hope this version resolves the concerns raised about the earlier version.
> 
> Bob Hinden
> IAOC Chair
> 
> p.s. I will be on vacation starting next week and will respond to comments 
> when I return.
> 
> 
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Julian Reschke]

On 10.09.2010 16:48, Ned Freed wrote:

...
Unfortunately, now that I've had a chance to look at
draft-daboo-et-al-icalendar-in-xml-06.txt a little more, I find that it doesn't
do this well. For example, instead of mapping a property like dtstamp to
something like:

 
   20080205T191224Z
 

it maps it to:

20080205T191224Z

This means that additional properties will necessitate a schema update. Not
good, and I believe this needs to be fixed.
...


Not really. How is adding a new allowed value to an XML attribute any 
different from adding a new element name (assuming a schema language 
than can express both constraints?).



...


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Ned,

--On September 10, 2010 7:48:26 AM -0700 Ned Freed  
wrote:



Unfortunately, now that I've had a chance to look at
draft-daboo-et-al-icalendar-in-xml-06.txt a little more, I find that it
doesn't do this well. For example, instead of mapping a property like
dtstamp to something like:


  20080205T191224Z


it maps it to:

   20080205T191224Z

This means that additional properties will necessitate a schema update.
Not good, and I believe this needs to be fixed.


There was a lot of debate over the choice of element names vs element 
attributes to name the iCalendar data objects. Really the key to your 
argument is whether or not it is vital to be able to validate the XML via 
the schema - I think our contention was that was not a requirement. More 
important is validating the semantics of the calendar data (e.g. DTEND 
always >= DTSTART, ORGANIZER always present in iTIP messages) and I believe 
no one is going to want to do that via the XML schema.


If you feel strongly about this I suggest you bring this issue up on the 
vCardDAV WG mailing list wrt to the vcard-in-xml spec which uses the same 
design as icalendar-in-xml. If there is agreement there to change, then we 
would likely re-align icalendar-in-xml to match.


--
Cyrus Daboo

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Keith Moore]

On Sep 10, 2010, at 10:24 AM, Cyrus Daboo wrote:

> Hi Keith,
> 
> --On September 10, 2010 10:09:11 AM -0400 Keith Moore  
> wrote:
> 
>>> That is precisely the goal of draft-daboo-et-al-icalendar-in-xml.
>>> iCalendar components, properties, parameters and values all map to XML
>>> in a consistent manner with no need to "special case" based on type or
>>> value.
>> 
>> But you're not doing that in the draft.  You explicitly list every
>> keyword.  Every time a new component, property, parameter, etc is added
>> to iCalendar, the mapping code will have to change also.  The trick is to
>> be able to translate between formats, with no changes to the code needed
>> even when the format is extended.
> 
> Fair enough. We can adjust e.g. Section 3.7 that talks about only X- 
> extensions to also refer to any new iCalendar data objects. The basic premise 
> being that new iCalendar data object names map directly to an XML element 
> name. After each table in the previous sections we can add a reference to 
> section 3.7 with a statement that that is how new items will be handled.

That would help.  But why do you need specific rules for any of the iCalendar 
data object names?  I can understand one or two exceptional cases, but if the 
mapping you have is truly adaptable, it shouldn't need many of those rules.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Keith,

--On September 10, 2010 12:43:53 PM -0400 Keith Moore 
 wrote:



Fair enough. We can adjust e.g. Section 3.7 that talks about only X-
extensions to also refer to any new iCalendar data objects. The basic
premise being that new iCalendar data object names map directly to an
XML element name. After each table in the previous sections we can add a
reference to section 3.7 with a statement that that is how new items
will be handled.


That would help.  But why do you need specific rules for any of the
iCalendar data object names?  I can understand one or two exceptional
cases, but if the mapping you have is truly adaptable, it shouldn't need
many of those rules.


OK, I'll discuss with my fellow authors to see what we can do to better 
clarify our intent. Maybe we actually state the naming/mapping rules at the 
very start of section 3 as the "fundamental" set of rules, but we still 
keep the tables in there as a useful reference back to the iCalendar spec.


--
Cyrus Daboo

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Laganier, Julien]

Alexandru Petrescu wrote:
> 
> Le 10/09/2010 11:58, Hesham Soliman a écrit :
> >
> > On 10/09/10 7:55 PM, "Alexandru
> > Petrescu" wrote:
> >
> >> Le 10/09/2010 11:48, Hesham Soliman a écrit :
> >
> > =>Who cares, specify it in your product description. The
> >   IETF doesn't specify how to build products.
> 
>  Hmm... to me it is a very IETF sensitive issue the Router vs
>  Host. For example, an ND spec says distinctively what a Host
>  and what a Router does, e.g. a Host does not respond to Router
>   Solicitation.
> >>>
> >>> =>   Yes and it does so on a per-interface basis, not on a
> >>> per-machine basis.
> >>
> >> Yes, and the Mobile Router is a Router on its egress interface
> >> when connected at home, as per spec.  It is that interface that
> >> needs a default route automatically configured.
> >
> > =>  Ok, so you're happy with it being half host half router when it's
> > away from home?
> 
> When it is away from home it is fully a Host on the egress interface.
> When at home fully Router on same.  I am happy with it this way.
> 
> > If so then let it do the same at home. Otherwise, I don't know how
> > you want to fix this in this WG.
> 
> It would mean to specify it to be a at home, be first a Host (get
> default route) then change and become a Router, but still at home.
>
> This behaviour could be set in the DHCPv6-PD-NEMO draft, being under
> discussion now.

This is a non issue for this draft. This is not specific to NEMO but generic to 
any DHCPv6 Prefix Delegation setup where the requesting router needs to 
configures an address on its north side. It can do so as per the deployment 
specifics, including, but not limited to, acting as a host on the north 
interface and as a router on south interfaces -- please remember that Neighbor 
Discovery is specified on a per-interface basis.

[ I also note that this draft has been more than 2 years in the MEXT working 
group in which you are participating, which gave you ample time to comment on 
this and other things... ]

--julien
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Keith Moore]

>>> An XML representation for iCalendar is vital if we are to keep iCalendar
>>> relevant in the web-based world. The drive for this work comes from a
>>> number of areas - in particular the smart grid effort sponsored by NIST
>>> will make use of this as part of the standards suite they are defining.
>> 
>> Somebody needs to talk some sense into those people.  Defining another
>> calendar format will only harm interoperability.  It doesn't save any
>> calendar implementation from needing to implement another parser, because
>> if it wants to interoperate with existing products or be able to read old
>> events it's still going to have to support iCalendar and probably
>> vCalendar also.  So what's the _technical_ (not political) benefit from
>> doing this?
> 
> First of all look at the mess we have got into with contacts (see recent 
> discussion on the vcarddav WG mailing list). There we now have vCard, PoCo, 
> OpenSocial and some new thing the OMA is doing (and their are lots of private 
> apis too). Yet vCard has been around for a long time - why didn't those other 
> folks just use that or at least propose fixes or extension to vcard that 
> would satisfy their issues? Well, certainly in the case of PoCo one clear 
> requirement was for a simple web/browser based solution - so they designed 
> JSON and XML representations.

Mumble.  It's a lot harder to make a web browser do something useful with a 
calendar object (no matter what the syntax) than it is to make a web browser do 
something useful with contact information.  

And I *like* JSON.  I think it's a good approximation to what XML should have 
been. 

And I can even see that having a DOM-based representation of calendar data for 
internal use in a program, as awkward as that is, might be better than lots of 
ad hoc internal representations.   (I can't quite put my finger on it, but 
there does seem to be something about iCalendar that encourages building poor 
internal representations of the data.)

Still, if I were designing a PIM that wanted to be able to have web browsers 
manipulate contact information, I'd use vCard as the interchange format and use 
JSON only for the purpose of communicating with Javascript code in the browser.

> The same mess could happen to iCalendar too. In fact there are already lots 
> of examples of "private" apis using XML to represent calendar data, see e.g. 
> Google GDATA. Plus I know of some public event services that uses their own 
> custom XML format for event publishers to submit calendar data to them. In 
> fact the initial impetus for this work did come from one such public events 
> company that really wanted to use iCalendar rather than some home grown 
> solution, but really wanted that as XML. Sure you can argue that they should 
> be made to parse iCalendar format, but why should they have to write their 
> own new parser when they already have reliable, efficient XML processing 
> available.

Code reuse is all the rage these days.  Can't they leverage work that someone 
else has already done?  

> Frankly the important thing here is the semantics of the iCalendar model, not 
> the syntax. I want developers to only have to concentrate on getting the 
> semantics right without worry too much about the syntax.

As much as I'd like to believe you can separate the model from the syntax, 
experience seems to indicate otherwise.  Every time I've seen people borrow a 
data model from one protocol and move it to another, the data models used by 
the two protocols have diverged.Think about the differences between 
interpretation of email header fields and HTTP header fields.  The field names 
get borrowed, the syntax of each field generally stays the same, but the 
semantics change. 

And there are reasons why the semantics change.  In the case of calendar data, 
consider timezone handling.  If you're sending out an event "in the blind" (say 
over email) without knowing whether the recipient will recognize your event 
timezone, you want to send as much mapping data as the receiver will need - 
even though it might change.  But if you're sending the event over some link 
that permits interaction and negotiation, you probably want to either ask the 
receiver whether it supports the timezone, or give it a link to the timezone 
data so that it can refresh it as needed.

This also reminds me of why IETF avoids standardizing APIs: it's because people 
tried to use the API (which is pretty much just a data model) as the basis for 
interoperability rather than bits on the wire.  And it didn't work.

> Now I can understand your concern about poor interoperability when it comes 
> to having the two data formats. I think for the HTTP-based world (CalDAV, 
> iSchedule, web-services) this is really not a big deal given the content 
> negotiation options. For something like iMIP (iCalendar in email) it is a 
> much bigger problem. Speaking for myself only, and not my co-authors, I think 
> I would be OK with adding 

Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Alexandru Petrescu]

Le 10/09/2010 18:57, Laganier, Julien a écrit :

Alexandru Petrescu wrote:


Le 10/09/2010 11:58, Hesham Soliman a écrit :


On 10/09/10 7:55 PM, "Alexandru
Petrescu"  wrote:


Le 10/09/2010 11:48, Hesham Soliman a écrit :


=> Who cares, specify it in your product
description. The IETF doesn't specify how to build
products.


Hmm... to me it is a very IETF sensitive issue the Router
vs Host. For example, an ND spec says distinctively what a
Host and what a Router does, e.g. a Host does not respond
to Router Solicitation.


=>Yes and it does so on a per-interface basis, not on a
per-machine basis.


Yes, and the Mobile Router is a Router on its egress interface
 when connected at home, as per spec.  It is that interface
that needs a default route automatically configured.


=>   Ok, so you're happy with it being half host half router
when it's away from home?


When it is away from home it is fully a Host on the egress
interface. When at home fully Router on same.  I am happy with it
this way.


If so then let it do the same at home. Otherwise, I don't know
how you want to fix this in this WG.


It would mean to specify it to be a at home, be first a Host (get
default route) then change and become a Router, but still at home.

This behaviour could be set in the DHCPv6-PD-NEMO draft, being
under discussion now.


This is a non issue for this draft. This is not specific to NEMO but
generic to any DHCPv6 Prefix Delegation setup where the requesting
router needs to configures an address on its north side.


Right... and a default route - that's the blocking point to me: I have
all this shiny software and RFC but no automatic default route, I have
to manually configure it.


It can do so as per the deployment specifics, including, but not
limited to, acting as a host on the north interface and as a router
on south interfaces -- please remember that Neighbor Discovery is
specified on a per-interface basis.


It's not sufficient to say Mobile Router always acts as a Host on the
North interface.  Because it must act as a Router too on its North
interface.  It must join the all-routers multicast address on the home
link, in order to forward packets from hosts on the home links towards LFNs.

If you don't like my default route comment then you could also just
write in DHCPv6-PD-NEMO "this does not configure a default route on the
Mobile Router, neither SLAAC".


[ I also note that this draft has been more than 2 years in the MEXT
working group in which you are participating, which gave you ample
time to comment on this and other things... ]


Note taken and I owe explanation.  If you wish consider my comments
non-blocking, as comments to a soon-to-be-Request-For-Comments.

I simply did not have neither the software nor the network testbed to
prototype until now.  Obtaining that is not easy, takes planning and
time. E.g. a stable DHCPv6-PD was available only lately from ISC despite
early initial availability.  It was mainly written for ISP-to-House
deployments which are very different than Mobile Router moving around.

If you wish too, you could bring it back from IESG to here and I will
comment further on it to work with real Relay, to solve
the sync between Prefix Table, Routing Table, radvd.conf, lease file, to
require Relay to insert route (currently it doesn't!), to respect 'M',
and so on.

Or we could just deliver to IESG and see past.  I am fine with all
options.

Alex



--julien




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Peter Saint-Andre]

On 9/10/10 11:21 AM, Keith Moore wrote:
> 
 An XML representation for iCalendar is vital if we are to keep
 iCalendar relevant in the web-based world. The drive for this
 work comes from a number of areas - in particular the smart
 grid effort sponsored by NIST will make use of this as part of
 the standards suite they are defining.
>>> 
>>> Somebody needs to talk some sense into those people.  Defining
>>> another calendar format will only harm interoperability.  It
>>> doesn't save any calendar implementation from needing to
>>> implement another parser, because if it wants to interoperate
>>> with existing products or be able to read old events it's still
>>> going to have to support iCalendar and probably vCalendar also.
>>> So what's the _technical_ (not political) benefit from doing
>>> this?
>> 
>> First of all look at the mess we have got into with contacts (see
>> recent discussion on the vcarddav WG mailing list). There we now
>> have vCard, PoCo, OpenSocial and some new thing the OMA is doing
>> (and their are lots of private apis too). Yet vCard has been around
>> for a long time - why didn't those other folks just use that or at
>> least propose fixes or extension to vcard that would satisfy their
>> issues? Well, certainly in the case of PoCo one clear requirement
>> was for a simple web/browser based solution - so they designed JSON
>> and XML representations.
> 
> Mumble.  It's a lot harder to make a web browser do something useful
> with a calendar object (no matter what the syntax) than it is to make
> a web browser do something useful with contact information.
> 
> And I *like* JSON.  I think it's a good approximation to what XML
> should have been.

It's not clear to me how your personal preference for JSON over XML is
relevant to registration of the application/calendar+xml media type or
continued work on draft-daboo-et-al-icalendar-in-xml. However, given
that you seem to object to the XML representation of vCards, calendaring
objects, and just about anything else, I suggest that you start a thread
about XML vs. JSON on the apps-discuss list rather than filling up the
archives of the ietf-types and ietf@ietf.org lists.

https://www.ietf.org/mailman/listinfo/apps-discuss

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[ned+ietf]

On 10.09.2010 16:48, Ned Freed wrote:
> ...
> Unfortunately, now that I've had a chance to look at
> draft-daboo-et-al-icalendar-in-xml-06.txt a little more, I find that it 
doesn't
> do this well. For example, instead of mapping a property like dtstamp to
> something like:
>
>  
>20080205T191224Z
>  
>
> it maps it to:
>
> 20080205T191224Z
>
> This means that additional properties will necessitate a schema update. Not
> good, and I believe this needs to be fixed.
> ...



Not really. How is adding a new allowed value to an XML attribute any
different from adding a new element name (assuming a schema language
than can express both constraints?).


First of all, there are many situations where you don't get to pick your schema
lannguage. (In fact I'd say it's the rule rather than the exception.) So even
there are Schema languages that support "any element can appear here" - the
fact that XML Schema doesn't allow this (xs:any has far too many restrictions
placed on it to be usefullly usable) means you shouldn't be defining things
this way.

Second, it is of course possible to impose restrictions on the values that can
appear in an attribute value (or element content for that matter). But just
because you can doesn't mean you should. And these sorts of mappings are
exactly the place where you shouldn't be doing this, at all, ever, because when
you do you end up having to change the schema for each extension that adds
properties (in the case of iCal) or actions/tests/controls (in the case of
Sieve).

Furthermore, in the case of Sieve at least, there are cases where it is
entirely valid to specify tests and actions in a script that the implementation
you're currently using doesn't support. For example:

   require "ihave";
   if ihave "ereject" { ereject "I hate this message"; }
   elsif ihave "reject" { reject "I still hate this message";}
   else { discard; }

or:

   require "ihave";
   if ihave "x-private-extension-nobody-else-has-heard-of" {
 if bletch "bar" "foo" { frob :zing "foo" 1 "bar";}
   }

If I've mapped actions and tests to elements here I'm screwed - there's no way
to make this work properly in XML Schema without either adding a ton of
superfluous bracketing elements all over the place (and we already have too
many of these), or creating a false distinction between extensions and base
elements that is, if anything, even uglier.

It's also easy to show that full script validity checking here requires solving
the satisfiability problem, which means its in NP. I'm pretty sure that exceeds
the capabilities of most schema languages ;-)

I believe similar issues exist in iCal and probably vCard.

Ned
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Keith Moore]

On Sep 10, 2010, at 12:39 PM, Phillip Hallam-Baker wrote:

> 
> 
> On Fri, Sep 10, 2010 at 10:48 AM,  wrote:
> 
> Even if XML-specific tools like stylesheets prove less than useful in
> performing manipulations of calendar data, there's still significant benefit
> associated with being able to use built in parsing capbilities, espcially when
> those capabilites are nicely tied to automatic creation of complex data
> stuctures in various languages.
> 
> What many XML-haters do not understand is that the syntax is designed to 
> completely automate the process of writing the parser and the backing data 
> classes.

I, at least, understand that.  But in my experience the backing data classes 
generally end up being ridiculously baroque.

> Starting with an XML Schema definition I can generate the corresponding data 
> structures automatically with one mouse click together with the corresponding 
> parser/serializer calls.
> 
> 
> Starting from an EBNF description, I have to first read the description. This 
> has already taken more time than working with the XML version would.

Really you should be able to generate the parser from the *BNF.   But you're of 
course correct that it won't generate the data structures for you.   All you 
get is a state machine that recognizes the language.

> I then have to work out if the grammar is an FSM or LR(1) or something else. 
> When I was a grad student I used to write yacc parsers but these days I have 
> written enough parser generators that I can actually hand code quicker than 
> it takes me working round the peculiarities of yacc.

Biggest problem I had with using yacc based parsers was doing good error 
recovery, because people would inevitably generate data representations that 
didn't quite fit the grammar.  But XML parsers tend to not be much better at 
that than yacc is.   With both XML and yacc, either the entire message is 
recognized or it isn't, unless you do a fair bit of work (often redefining the 
language in the process).

> So what takes me no time at all with XML is likely to take a couple of days 
> and considerably more skill with EBNF.

Granted.  But surprisingly, this actually comes at a cost.  When every protocol 
had its own syntax for representing data, there was pressure to keep the data 
models from getting too complex.  With XML, people are free to make the data 
models as complex as they want - and often, this means that the data models are 
not well thought out.   That's not to say that having a standard, uniform 
presentation syntax which translates readily to and from an internal data 
structure is a bad thing.   (Even if I don't like XML specifically, I think the 
underlying goal is sound.)  What it means is that protocol designers and data 
model designers still need to exercise discipline to keep their data models 
simple.

(not that any of the above has much to do with iCalendar, since the data model 
there is already largely determined.)

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Optimizing for what? Was Re: IETF Attendance by continent

[Dave CROCKER]

On 9/7/2010 5:41 PM, Ross Callon wrote:

It's my sense that it's increasingly difficult to do work in the IETF
without being physically present at meetings, as well...


I think that this has been true since the first IETF (at least if you
replace the word "increasingly" with the word "very").



Face-to-face is quite helpful for forming an effort, since it creates a
connection among the group, and it is quite helpful for resolving specific
problems.  That is, it is good for personal connection and rapid interaction.

For a group with real focus and a strong sense of purpose, face to face is /not/
all that important for general document development and revision, absent
particular points of impasse.

So the 'very' Ross cites has always been true, but in constrained ways.

Useful documents can be developed with /no/ face-to-face interactions.  Useless
documents are often developed with /primarily/ face-to-face interactions.
Neither mode has a guaranteed outcome.

IMO, the tendency to move more towards doing work in f2f meetings seems
primarily to indicate a lack of urgency, process management and/or technical
focus, rather than on an actual need.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The Evils of Informational RFC's

[Dave CROCKER]

I fail to find any of the justifications in RFC 4846 all that persuasive.
Choosing a few examples:

...

Nowadays, vendors have web sites that describe their protocols.



These are frequent lines of argumentation against publishing anything other than 
formal IETF documents.  What they represent is a misunderstanding of the 
established role of the RFC series.  Publishing formal IETF documents is only 
part of the benefit provided to the community for the last 40 years.


Take a look back over that record.  Its structure and publication arc describe a 
culture, not just a set of technologies.


A healthy community culture is difficult to engineer and fragile to maintain. 
Typically, it's creation is an unintended consequence and it is destroyed 
similarly.  Mess with it not just at your own peril, but at the peril of that 
community.


There is no crisis or even problem that is creating different circumstances than 
we have had over the last 40 years.  We have flourished, not just survived, with 
this horribly flawed publishing model.  Note, for example, that alternative 
publishing might be more convenient now, but it is not new. In other words, it 
ain't broke, so let's stop calling for repair.


We would spend our time better by focusing on creating our own specifications 
more efficiently and with better and quicker community uptake.  Worrying about 
non-IETF Informational IETFs distracts from that.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Optimizing for what? Was Re: IETF Attendance by continent

[Dave CROCKER]

On 9/7/2010 2:50 PM, Michael StJohns wrote:

Dave and I don't always agree :-)

I don't think we've got either the database of "people not attending because
of costs" nor a good model for factoring them in if we did (e.g. N pnac's


Well, we agree on this.  But I class this as a failure or at least a problem, 
rather than something to accept.




We have good data on past attendees.  From that we can probably build a
pretty good model on what each past attendees Pa (percentage chance of


This is called selling to the installed base.  It's important to pay attention 
to the installed base of participants, but it is death for an organization to 
pay attention /only/ to that base.  It's form of incest, and really destroys the 
adaptive DNA of the organization.  Withers on the vine, loses touch with 
reality, etc. etc.




Let's stick with solid data rather than try and resolve the hypotheticals - I
doubt the latter is possible in any meaningful way.


My point is that we need to reach out empirically, to get input from potential 
attendees, not just from guaranteed attendees.  The fact that there is some 
challenge in identifying and contacting these new folk does not make it less 
important that we do it.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Dave CROCKER]

On 9/9/2010 8:38 PM, Ned Freed wrote:

This was a bad idea when it was first proposed (if I recall correctly) around
ten years ago, and it's still a bad idea.


I strongly disagree.


Whenever you define an alternate representation of something, there will
inevitably be skew between the original representation and the alternate
representation.


This is demonstrably false.



We need to distinguish between alternate syntactic forms, versus alternate 
semantic environments.  Translating between versions of the former do not need 
to lose information.  Translating between versions of the latter almost 
certainly do.  Losing information is about differences in semantics.


As I understand the calendar+xml, it is "merely" a syntactic alternative.  To 
the extent that it requires information loss when being re-encoded, yes that 
should be fixed.  But it's not likely to be difficult and the existence of two 
syntactic forms is not inherently problematic.  (We have lots of examples on the 
net of doing this quite nicely, at different layers of Internet architecture.)


As for the more abstract discussion about whether it's good or bad to have an 
xml version, I'll strongly suggest that it is best conducted in a real bar bof 
with real alcohol.  (I'll be supporting its existence, FWIW.)  The xml version 
is an important fact of life.  Let's not pretend otherwise.


It is not the job of the MIME registration process to make political statements 
that give preferential treatment to facts of life that some might like more than 
other facts of life...


Register the damn thing.  The registration form appears to satisfy registration 
requirements.


If there are specific problems with the associated spec, pursue them 
independently and concretely, please.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Hesham Soliman]

On 9/09/10 4:28 PM, "Alexandru Petrescu" 
wrote:

> Le 09/09/2010 08:01, Hesham Soliman a écrit :
>> 
>> 
>> 
>> On 9/09/10 3:54 PM, "Wassim Haddad"
>> wrote:
>> 
>>> On Sep 8, 2010, at 7:58 AM, Alexandru Petrescu wrote:
>>> 
 I agree mainly with the document draft-ietf-mext-nemo-pd.
 
 It is good and needed to dynamically assign a Mobile Network
 Prefix to the NEMO-enabled Mobile Router.
 
 However, here are a couple of missing points.
 
 One missing point is about how will the Mobile Router configure
 its default route on the home link?  I thought Prefix Delegation
  would bring DHCP in the picture and would allow MR to synthesize
  a default route even though RAs are absent.  But I now realize
 that a DHCPv6-PD implementation (and std?) does not allow a
 router (MR) to synthesize its default route (neither RA does, nor
 DHCPv6-nonPD does).
>> 
>> =>  I think the MR can easily act as a host on its egress interface
>> and configure its default/next hop router that way. Of course the
>> other alternative is to use routing protocols, but I think using ND
>> should be sufficient.
> 
> Hesham - when at home, the MR acts  as a router (ip_forward==1,
> join all-routers group), as such ND is insufficient to obtain the
> default route - it's a Router.
> 
> When at home, and using DHCPv-PD, the MR also acquires its Home Address
> with DHCPv6.  If so, then it doesn't use SLAAC to auto-configure neither
> a Home Address nor a default route.
> 
> In implementation it is of course possible to dynamically change MR
> behaviour from Host to Router: be at home, first act as host (fwd==0) to
> acquire the Home Address and default route, then set fwd=1 and use
> DHCPv6-PD to acquire a prefix (but not the Home Address) and take
> advantage of the default route acquired previously as a Host.  This is
> one way of solving the issue.

=> Exactly. 

 However it is not specified.

=> Who cares, specify it in your product description. The IETF doesn't
specify how to build products. If you want to solve this with protocols then
use routing protocols. Of course you need to solve the security issues when
the MR moves. 

I am not
> sure how clean is it anyways to disregard that 'M' bit of RA anyways.
> 
> The alternative to using routing protocols (OSPF?) to communicate a
> default route to the MR - I am not sure how this could work, never seen
> it in practice.

=> For  a good reason! You need to work out trust across domains.

Hesham

> 
> Alex
> 
> 
>> 
>> Hesham
>> 
>> 
>> 
>> 
>> 
> 
> 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Latest Development in DiffServ Wars

[Phillip Hallam-Baker]

There are two possibilities here:

1) The Press Release is accurate in its representation of the IETF

No action is required

2) Someone on the Internet is wrong

No action is required.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Phillip Hallam-Baker]

The objections raised by Keith do not appear to me to fall under any of the
requirements for MIME type registration set out in RFC 4288.


I disagree with the argument made in any case.

If you want to have a system in which 95% of your data structures are in XML
you probably don't want to have to introduce a separate syntax and you most
certainly do not want to deal with a separate data model for dealing with
calendaring.

The iCalendar format represents a 1990s style approach to the problem. There
is no real separation of syntax from the data model. Software developed in
that manner is notoriously difficult to get right for the reasons that Keith
describes.

XML is a substantial overhead if you are dealing with a single protocol but
when you are dealing with multiple protocols the benefits are substantial
and allow something like 70% of your coding effort to be pushed onto the
platform layer. That means that you have 70% less new code and new code
paths to contend with.

One of the discoveries of the mid 1990s was that yacc and LR(1) grammars are
no more useful for describing computer languages than they are for
describing natural languages. The most useful feature of a computer grammar
is regularity and consistency. XML enforces a high degree of consistency.


Now I would quite prefer to take about 50% or more of the XML spec and
discard it. They did a good job of taking out the most insane features of
SGML but there is much more cruft that could be cut out. But that does not
change the fact that using XML as is produces clearer specifications that
are more likely to be implemented without errors than with the 1990s
approach.


On Thu, Sep 9, 2010 at 10:51 PM, Keith Moore  wrote:

>
> --
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Hesham Soliman]

>> 
>> =>  Who cares, specify it in your product description. The IETF
>> doesn't specify how to build products.
> 
> Hmm... to me it is a very IETF sensitive issue the Router vs Host.  For
> example, an ND spec says distinctively what a Host and what a Router
> does, e.g. a Host does not respond to Router Solicitation.

=> Yes and it does so on a per-interface basis, not on a per-machine basis.

Hesham

> 
> In this same way a Router should dynamically be able to obtain a default
> route, in addition to a Host doing so.
> 
> The products sold are neither Hosts nor Routers - they're BFRs, servers,
> desktops, tablets, laptops.
> 
>> If you want to solve this with protocols then use routing protocols.
>> Of course you need to solve the security issues when the MR moves.
> 
> But SLAAC (what you call ND) is not a routing protocol yet does deliver
> a default route, only to Hosts.  DHCPv6 is not a routing protocol either
> but does not deliver a default route neither to Hosts nor to Routers.
> 
> (I am not clear whether the DHCPv6 spec forbids delivery of a default
>   route; or allows; I have to check; the implementation does not.)
> 
>> I am not
>>> sure how clean is it anyways to disregard that 'M' bit of RA
>>> anyways.
>>> 
>>> The alternative to using routing protocols (OSPF?) to communicate a
>>> default route to the MR - I am not sure how this could work, never
>>> seen it in practice.
>> 
>> =>  For  a good reason! You need to work out trust across domains.
> 
> Probably...
> 
> Alex
> 
>> 
>> Hesham
>> 
>>> 
>>> Alex
>>> 
>>> 
 
 Hesham
 
 
 
 
 
>>> 
>>> 
>> 
>> 
>> 
> 
> 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Hesham Soliman]

On 10/09/10 7:55 PM, "Alexandru Petrescu" 
wrote:

> Le 10/09/2010 11:48, Hesham Soliman a écrit :
>> 
>> 
 
 =>   Who cares, specify it in your product description. The IETF
  doesn't specify how to build products.
>>> 
>>> Hmm... to me it is a very IETF sensitive issue the Router vs Host.
>>> For example, an ND spec says distinctively what a Host and what a
>>> Router does, e.g. a Host does not respond to Router Solicitation.
>> 
>> =>  Yes and it does so on a per-interface basis, not on a
>> per-machine basis.
> 
> Yes, and the Mobile Router is a Router on its egress interface when
> connected at home, as per spec.  It is that interface that needs a
> default route automatically configured.

=> Ok, so you're happy with it being half host half router when it's away
from home? If so then let it do the same at home. Otherwise, I don't know
how you want to fix this in this WG.

Hesham


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Hesham Soliman]

> 
> When it is away from home it is fully a Host on the egress interface.
> When at home fully Router on same.  I am happy with it this way.
> 

=> Ok that doesn't make any sense to me.

>> If so then let it do the same at home. Otherwise, I don't know how
>> you want to fix this in this WG.
> 
> It would mean to specify it to be a at home, be first a Host (get
> default route) then change and become a Router, but still at home.

=> Ditto.

Hesham

> 
> This behaviour could be set in the DHCPv6-PD-NEMO draft, being under
> discussion now.
> 
> Alex
> 
>> 
>> Hesham
>> 
>> 
>> 
> 
> 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Phillip Hallam-Baker]

On Fri, Sep 10, 2010 at 6:11 AM, Julian Reschke wrote:

> OK, enough :-)
>
> Can we please switch to a discussion of the RFC publication format now?
>
> Best regards, Julian
>

If people do not like my approach to designing protocols and want to
persuade the market to adopt a different approach they should consider
adopting my proposals for making the RFC publication format more likely to
be influential.


The reason we use XML is to achieve Bill Gate's vision of 'frictionless
capitalism'. Tests conducted by the World Wide Web Consortium in the MIT
wind tunnel conclusively demonstrated that the angle brackets have the
lowest drag coefficient of any ASCII punctuation character.

-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Phillip Hallam-Baker]

At one time there were people who whined one endlessly about the evils of
HTML email.

And before that there was a guy who used to drone on endlessly in comp.arch
about how high level languages were a mistake and how everything should be
written in machine code.

The technology world moves on. Either deal with it or open a museum.



On Fri, Sep 10, 2010 at 10:59 AM, Julian Reschke wrote:

> On 10.09.2010 16:45, Cyrus Daboo wrote:
>
>> ...
>>
>>  IETF's job is to provide technical leadership, not to follow bad advice.
>>> Instead of caving into them, what we need to do is publish a draft called
>>> "Translating Everything into XML Considered Harmful".
>>>
>>
>> Ah, yes. I seem to recall something similar for the use of HTTP -
>> perhaps the author of RFC 3205 would like to author this new document
>> too :-)
>> ...
>>
>
> In which case I'd be tempted to follow up with
>
> "Inventing unnecessary new protocols, URI schemes and media types
> considered harmful as well - find a good balance, please"
>
> :-)
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Registration of media type application/calendar+xml

[Phillip Hallam-Baker]

On Fri, Sep 10, 2010 at 10:48 AM,

> wrote:

>
> Even if XML-specific tools like stylesheets prove less than useful in
> performing manipulations of calendar data, there's still significant
> benefit
> associated with being able to use built in parsing capbilities, espcially
> when
> those capabilites are nicely tied to automatic creation of complex data
> stuctures in various languages.
>

What many XML-haters do not understand is that the syntax is designed to
completely automate the process of writing the parser and the backing data
classes.

Starting with an XML Schema definition I can generate the corresponding data
structures automatically with one mouse click together with the
corresponding parser/serializer calls.


Starting from an EBNF description, I have to first read the description.
This has already taken more time than working with the XML version would.

I then have to work out if the grammar is an FSM or LR(1) or something else.
When I was a grad student I used to write yacc parsers but these days I have
written enough parser generators that I can actually hand code quicker than
it takes me working round the peculiarities of yacc.

So what takes me no time at all with XML is likely to take a couple of days
and considerably more skill with EBNF.


Of course this approach works best in modern languages like Java and C# but
I have generated similar tools for C and I am pretty sure the same tools
exist for objective C. Its going to suck somewhat if you are coding in
FORTRAN or Pascal.

-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: NAT behavior for IP ID field

[Fernando Gont]

Hi,

>>> I'm trying to locate an RFC that spells out the behavioral
>>> requirements, expectations or guidelines for NAT handling of the IP ID
>>> field, particularly for UDP messages.
>>> If this is not written down anywhere, do NATs generally rewrite the ID
>>> field with or without the MF bit set?
>> I don't know.
>>
>> We had a discussion about this in the BEHAVE working group while working on
> stateful IPv6-to-IPv4 translation. Unless I missed something, the ID field 
> needs
> uniqueness for any combination of source, destination IP addresses and 
> protocol.
> Assuming the source address doesn't change, this means an ID counter should be
> maintained per destination address + protocol pair, so the maximum number of
> packets can be transmitted for each such pair before an ID value is reused. 
> This
> would be the optimal host behavior, and NATs should act like hosts in this
> regard. Reusing the ID field from the original packet has a much higher chance
> of seeing the same ID field for outstanding fragments of a different flow, 
> which
> can cause undetected data corruption in 1 in 65535 cases when the TCP/UDP
> checksum doesn't catch this.

The same applies to other TCP and IP header fields.
draft-gont-behave-nat-security contains some discussion of this.



> Curious; RFC2402 says
> "  Flags -- This field is excluded since an intermediate router might
>  set the DF bit, even if the source did not select it."
> which is a licence to set the bit but I had not thought to reset the bit.
> RFC791,  RFC1122 and RFC1812 would appear to be silent on this.

I'm curious abut RFC 2402, then. Firstly, the host might not implement
PMTUD, and hence setting the DF bit on its behalf could possibly cause
interoperability problems. Secondly, some hosts clear the DF bit if the
advertised MTU in an ICMP "frag needed" is below some specified
threshols. This RFC2402-behavior could cause problems in this scenario, too.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Laganier, Julien]

Alexandru Petrescu wrote:
> 
> Le 10/09/2010 18:57, Laganier, Julien a écrit :
> > Alexandru Petrescu wrote:
> >>
> >> Le 10/09/2010 11:58, Hesham Soliman a écrit :
> >>>
> >>> On 10/09/10 7:55 PM, "Alexandru
> >>> Petrescu"  wrote:
> >>>
>  Le 10/09/2010 11:48, Hesham Soliman a écrit :
> >>>
> >>> => Who cares, specify it in your product
> >>> description. The IETF doesn't specify how to build
> >>> products.
> >>
> >> Hmm... to me it is a very IETF sensitive issue the Router
> >> vs Host. For example, an ND spec says distinctively what a
> >> Host and what a Router does, e.g. a Host does not respond
> >> to Router Solicitation.
> >
> > =>Yes and it does so on a per-interface basis, not on a
> > per-machine basis.
> 
>  Yes, and the Mobile Router is a Router on its egress interface
>   when connected at home, as per spec.  It is that interface
>  that needs a default route automatically configured.
> >>>
> >>> =>   Ok, so you're happy with it being half host half router
> >>> when it's away from home?
> >>
> >> When it is away from home it is fully a Host on the egress
> >> interface. When at home fully Router on same.  I am happy with it
> >> this way.
> >>
> >>> If so then let it do the same at home. Otherwise, I don't know
> >>> how you want to fix this in this WG.
> >>
> >> It would mean to specify it to be a at home, be first a Host (get
> >> default route) then change and become a Router, but still at home.
> >>
> >> This behaviour could be set in the DHCPv6-PD-NEMO draft, being
> >> under discussion now.
> >
> > This is a non issue for this draft. This is not specific to NEMO but
> > generic to any DHCPv6 Prefix Delegation setup where the requesting
> > router needs to configures an address on its north side.
> 
> Right... and a default route - that's the blocking point to me: I have
> all this shiny software and RFC but no automatic default route, I have
> to manually configure it.

If you agree that this is generic to DHCPv6 prefix delegation and not limited 
to this specific application of DHCPv6 prefix delegation to a NEMO environment, 
then this draft can proceed.

If you are missing a mechanism to get a default route on a DHCPv6 prefix 
delegation requesting router, you can write a draft and submit it to the DHC WG.

I also don't know what the problem is on most cases. Presumably the requesting 
router's default route is to send packet to the delegating router. 

> > It can do so as per the deployment specifics, including, but not
> > limited to, acting as a host on the north interface and as a router
> > on south interfaces -- please remember that Neighbor Discovery is
> > specified on a per-interface basis.
> 
> It's not sufficient to say Mobile Router always acts as a Host on the
> North interface.  Because it must act as a Router too on its North
> interface.  It must join the all-routers multicast address on the home
> link, in order to forward packets from hosts on the home links towards
> LFNs.
> 
> If you don't like my default route comment then you could also just
> write in DHCPv6-PD-NEMO "this does not configure a default route on the
> Mobile Router, neither SLAAC".

You agreed earlier that this is generic to DHCPv6 prefix delegation and not 
specific to NEMO so this draft is NOT the place to digress on default routes 
for DHCPv6 prefix delegation.
 
> > [ I also note that this draft has been more than 2 years in the MEXT
> > working group in which you are participating, which gave you ample
> > time to comment on this and other things... ]
> 
> Note taken and I owe explanation.  If you wish consider my comments
> non-blocking, as comments to a soon-to-be-Request-For-Comments.

As you agreed earlier that this is generic to DHCPv6 prefix delegation and not 
specific to NEMO I do not consider this as blocking. 
 
> I simply did not have neither the software nor the network testbed to
> prototype until now.  Obtaining that is not easy, takes planning and
> time. E.g. a stable DHCPv6-PD was available only lately from ISC
> despite early initial availability.  It was mainly written for ISP-to-House
> deployments which are very different than Mobile Router moving around.
> 
> If you wish too, you could bring it back from IESG to here and I will
> comment further on it to work with real Relay, to solve
> the sync between Prefix Table, Routing Table, radvd.conf, lease file,
> to require Relay to insert route (currently it doesn't!), to respect 'M',
> and so on.

We are not bringing it back to the MEXT WG for something that is not related to 
the MEXT WG but generic to DHCPv6 prefix delegation.
 
> Or we could just deliver to IESG and see past.  I am fine with all
> options.

This is what we are doing.

If you really think there's a missing piece, write a draft and submit it to the 
DHC WG.

--julien
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinf

Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Alexandru Petrescu]

Le 10/09/2010 23:18, Laganier, Julien a écrit :

Alexandru Petrescu wrote:


Le 10/09/2010 18:57, Laganier, Julien a écrit :

Alexandru Petrescu wrote:


Le 10/09/2010 11:58, Hesham Soliman a écrit :


On 10/09/10 7:55 PM, "Alexandru
Petrescu"   wrote:


Le 10/09/2010 11:48, Hesham Soliman a écrit :


=>  Who cares, specify it in your product
description. The IETF doesn't specify how to build
products.


Hmm... to me it is a very IETF sensitive issue the Router
vs Host. For example, an ND spec says distinctively what a
Host and what a Router does, e.g. a Host does not respond
to Router Solicitation.


=> Yes and it does so on a per-interface basis, not on a
per-machine basis.


Yes, and the Mobile Router is a Router on its egress interface
  when connected at home, as per spec.  It is that interface
that needs a default route automatically configured.


=>Ok, so you're happy with it being half host half router
when it's away from home?


When it is away from home it is fully a Host on the egress
interface. When at home fully Router on same.  I am happy with it
this way.


If so then let it do the same at home. Otherwise, I don't know
how you want to fix this in this WG.


It would mean to specify it to be a at home, be first a Host (get
default route) then change and become a Router, but still at home.

This behaviour could be set in the DHCPv6-PD-NEMO draft, being
under discussion now.


This is a non issue for this draft. This is not specific to NEMO but
generic to any DHCPv6 Prefix Delegation setup where the requesting
router needs to configures an address on its north side.


Right... and a default route - that's the blocking point to me: I have
all this shiny software and RFC but no automatic default route, I have
to manually configure it.


If you agree that this is generic to DHCPv6 prefix delegation and not limited 
to this specific application of DHCPv6 prefix delegation to a NEMO environment, 
then this draft can proceed.

If you are missing a mechanism to get a default route on a DHCPv6 prefix 
delegation requesting router, you can write a draft and submit it to the DHC WG.

I also don't know what the problem is on most cases. Presumably the requesting 
router's default route is to send packet to the delegating router.


It can do so as per the deployment specifics, including, but not
limited to, acting as a host on the north interface and as a router
on south interfaces -- please remember that Neighbor Discovery is
specified on a per-interface basis.


It's not sufficient to say Mobile Router always acts as a Host on the
North interface.  Because it must act as a Router too on its North
interface.  It must join the all-routers multicast address on the home
link, in order to forward packets from hosts on the home links towards
LFNs.

If you don't like my default route comment then you could also just
write in DHCPv6-PD-NEMO "this does not configure a default route on the
Mobile Router, neither SLAAC".


You agreed earlier that this is generic to DHCPv6 prefix delegation and not 
specific to NEMO so this draft is NOT the place to digress on default routes 
for DHCPv6 prefix delegation.


[ I also note that this draft has been more than 2 years in the MEXT
working group in which you are participating, which gave you ample
time to comment on this and other things... ]


Note taken and I owe explanation.  If you wish consider my comments
non-blocking, as comments to a soon-to-be-Request-For-Comments.


As you agreed earlier that this is generic to DHCPv6 prefix delegation and not 
specific to NEMO I do not consider this as blocking.


I simply did not have neither the software nor the network testbed to
prototype until now.  Obtaining that is not easy, takes planning and
time. E.g. a stable DHCPv6-PD was available only lately from ISC
despite early initial availability.  It was mainly written for ISP-to-House
deployments which are very different than Mobile Router moving around.

If you wish too, you could bring it back from IESG to here and I will
comment further on it to work with real Relay, to solve
the sync between Prefix Table, Routing Table, radvd.conf, lease file,
to require Relay to insert route (currently it doesn't!), to respect 'M',
and so on.


We are not bringing it back to the MEXT WG for something that is not related to 
the MEXT WG but generic to DHCPv6 prefix delegation.


Or we could just deliver to IESG and see past.  I am fine with all
options.


This is what we are doing.

If you really think there's a missing piece, write a draft and submit it to the 
DHC WG.


How about megoing to DHC saying this is needed for a NEMO Mobile Router? 
 They'dsay go to MEXT.  Or they'd say this is a SLAAC problem go to 
6MAN.  And so on.  But let me try anyways see what they think.


Alex



--julien



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Latest Development in DiffServ Wars

[Bob Hinden]

On Sep 9, 2010, at 4:46 PM, Phillip Hallam-Baker wrote:

> There are two possibilities here:
> 
> 1) The Press Release is accurate in its representation of the IETF
> 
> No action is required
> 
> 2) Someone on the Internet is wrong

That never happens!  Maybe the IETF should start a working group to insure that 
all information on the Internet is correct :-)

Bob


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Latest Development in DiffServ Wars

[Richard Bennett]

  
  
Fortunately, Housley's not as recalcitrant about correcting errors
as some hardheads would like. See this article from today, relevant
portions highlighted.

RB
Housely: IETF Has Taken No Position On AT&T
  Prioritization Assertions
Though group chairman personally thinks AT&T has
"jumbled some things together"
By John Eggerton -- Broadcasting & Cable, 9/10/2010
10:54:17 AM

   

Public interest groups including Free
Press and Public Knowledge have called on AT&T to retract a
letter to the
FCC that said the Internet standards-setting body IETF (Internet
Engineering
Task Force) had "fully contemplated" paid prioritization, with the
groups saying IETF disputed that assertion. But Russ Housely,
chairman of the
IETF, says that is not the case, though he said he personally thinks
AT&T
has "jumbled some things together."

Paid prioritization is one of two key
issues on which the FCC is seeking more comment before it proceeds
with its
effort to expand and codify network openness principles.

In AT&T's
  letter
it said Free Press was confused about paid prioritization in its own
letter.
AT&T has said that paid prioritization was contemplated by IETF,
is already
widely available from multiple providers, and is used by small
businesses as
well as the handful of giants Free Press says benefit from it. In a
blog
posting Thursday, AT&T SVP Bob Quinn, who signed the FCC letter,
defined
that prioritization as "providing customers the option of purchasing
a
higher quality of service."

Public Knowledge, Free Press and others
issued a release this week headlined "Internet Engineering Task
Force Says
‘AT&T Is Misleading' on Net Neutrality." They argue AT&T is
blurring the line between paid prioritization, which Free Press
defined as
"speeding up and slowing down" Internet traffic according to who
pays
more, and "accepted business-class network management practices."

The call for a retraction came after
Housely told the National Journal that the AT&T letter was
misleading. 

"IETF prioritization technology is
geared toward letting network users indicate how they want network
providers to
handle their traffic, and there is no implication in the IETF about
payment
based on any prioritization," he said.

But Housely says he was speaking for
  himself, not IETF. "I want to be clear that I was speaking as an
  individual when I spoke to reporters last Friday," he told the
  magazine in
  an e-mail. "The [public interest group] press release says: 'The
  IETF,
  however, disputes AT&T's claims.' The IETF has not taken any
  consensus
  position on this matter," he said, adding in a follow-up e-mail:
  "[T]he IETF produces technical specification for the Internet. The
  IETF
  does not make statements about prices for network services."

Compromise language being hammered out
by industry representatives, including AT&T and the National
Cable &
Telecommunications Association, on a legislative path to clarifying
the FCC's
Internet access oversight authority is likely to include an
agreement that paid
prioritization of service should be allowed, but with assurances
that such
prioritization does not come at the cost of the robustness of the
"public
Internet."

Housely says the "jumble"
comes from the meaning of "paid prioritization. "[I]t is clear to me
that the term "paid  prioritization" does not have the same
meaning to all readers," he told B&C.
"If you read the AT&T letter with one definition in your head,
then
you get one overall message, and if you read the letter with the
other in your
head, then you get a different overall message. I tried to make this
point."
 
Housely told B&C that AT&T in
its letter makes "many correct points"--he did not specify which
they
were--but that it also "jumbles some things together." "[I]n my
opinion, a
reader will get a distorted impression from the parts of the letter
where
things get jumbled," he said. 

  The problem, Housely says, is that the
  IETF specification at issue is not about "prioritization," but
  about
  quality of service. "Different applications need different
things from the
network to deliver a quality experience," he said. He used as an
example
of giving preference to "traffic associated with applications that
require
timely delivery, like voice and video, over traffic associated with
applications without those demands, like email." 

Housely says the debate is not about
that, but about what happens if, say, two video sites both mark
their packets

Re: Registration of media type application/calendar+xml

[Keith Moore]

[ietf-types removed to spare those who just want to read type applications.]

> We need to distinguish between alternate syntactic forms, versus alternate 
> semantic environments.  Translating between versions of the former do not 
> need to lose information.  Translating between versions of the latter almost 
> certainly do.  Losing information is about differences in semantics.

I'm not convinced that there is a difference in practice between the two.  
Different syntactic forms tend to get used in different environments, and to 
adapt to the requirements/conventions of those environments.  

calendar+xml is intended to be merely a syntactic alternative.  I just don't 
believe it is likely to stay that way.

> As I understand the calendar+xml, it is "merely" a syntactic alternative.  To 
> the extent that it requires information loss when being re-encoded, yes that 
> should be fixed.  But it's not likely to be difficult and the existence of 
> two syntactic forms is not inherently problematic.  (We have lots of examples 
> on the net of doing this quite nicely, at different layers of Internet 
> architecture.)

please cite specific examples.  it might be instructive to see why they work or 
don't work well.

the best one that immediately comes to mind is raw IP vs. PPP with header 
compression.  I think it works because the latter representation is only used 
on the wire between two endpoints of a network link.  And if it fails to 
faithfully reproduce the packet, it's very clear where the problem is.  
(there's no argument about which representation is correct - the original 
packet is always correct.).

> As for the more abstract discussion about whether it's good or bad to have an 
> xml version, I'll strongly suggest that it is best conducted in a real bar 
> bof with real alcohol.  (I'll be supporting its existence, FWIW.)  

I had to read that twice.  For a second I thought you were offering to support 
the existence of alcohol for the bar bof. 

> The xml version is an important fact of life.  Let's not pretend otherwise.

My standard response whenever anyone cites anything as "reality" or a "fact of 
life", is that that's what people always say when they can't cite any technical 
justification.  

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf