Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
--On Sunday, January 01, 2012 19:55 +0100 Bjoern Hoehrmann derhoe...@gmx.net wrote: Among the goals of the Internet Standards Process are openness and fairness and I would find these principles grossly violated if the IESG would approve the document for publication with the proposed changes applied but without another Last Call. With another Last Call and if there is rough consensus in favour of the changes, and that'd include running code, then that's fine with me, regardless of whether an intention to publish an Internet-Draft as RFC is communicated to some obscure W3C mailing list, or who communicates such an intention. Björn, For better or worse, the IETF tries to maintain close working relationships with a number of other SDOs. While there are exceptions, those relationships work best when we are willing to go out of our way to be sure that everyone stays informed and, in particular, that we don't appropriate their standards or conventions and start making changes to them... and when they reciprocate. While different ADs handle it differently, we have also traditionally made the assumption that authors requesting individual submission publication have to take most of the responsibility for making sure all of the ducks are lined up. They cannot, for example, rely on a WG to do that (since there isn't one) nor on IETF Last Call to spot everything that they, who are presumably expert enough to have constructed the document in the first place, should have spotted. That said, I basically agree with what you have written above, tempered by the understanding that I think it is in the IETF's best interest (as well as just plain polite) to go to W3C and say, repeatedly if necessary, do you really, really, not have anything to say about this? We certainly expect the same from other SDOs we work with and W3C has give us that courtesy on some occasions when we have been slow to respond. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-6lowpan-nd-18.txt (Neighbor DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) toProposed Standard
Hi: I posted support for this draft to the WG mailing list. At the same time, I regretted the lack of a sequence counter in the registration mechanism. Ralph suggested that I share my concerns in this step of the review process. The sequence counter existed in earlier versions of the draft and was called a TID (see http://tools.ietf.org/html/draft-ietf-6lowpan-nd-08#page-18). Similar sequence counters exist in other registration mechanisms such as MIPv6. The sequence counter is useful for: 1) anti-replay 2) correlation of requests and responses in case messages cross (e.g. in mesh under) 3) mobility support (when radio conditions change, a device might need to select an alternate router) Items 1 and 2 were not enough to convince the authors to keep the TID, and item 3 is somewhat an external to the specification. Yet, item 3 is the one I'm most concerned with, because it is required in order to inject the registration in a routing protocol such as RPL, or over a backbone in an ND proxy operation as was supported in earlier versions of the draft (till 8). In the case of RPL, the path sequence in the transit option is used to determine which path is stale after a movement as described in http://tools.ietf.org/html/draft-ietf-roll-rpl-19#section-9.2.1 . The TID would be trivially mapped into that path sequence but cannot be regenerated by the attachment router should the device move. IOW, without a TID, a device must be hardwired to its router for RPL to operate properly. RPL is very explicit about that limitation in section 7.1: If a host does not pass a counter to its router, then the router is in charge of computing the Path Sequence on behalf of the host and the host can only register to one router for that purpose. In the case of the backbone router that is now discussed separately from ND in http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-02, we want a transparent mobility for the constrained device, so we need a mechanism to determine the freshest of conflicting registrations. The backbone routers would use the TID to figure which registration is freshest and determine which router should proxy over the backbone. In any case, it appears that though the ND mechanism could probably live without a sequence counter in most cases, a sequence counter is quite critical for the global integration of the protocol in a multi-hop radio infrastructure. What do you think? Pascal -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: vendredi 16 décembre 2011 22:02 To: IETF-Announce Cc: 6low...@lists.ietf.org Subject: Last Call: draft-ietf-6lowpan-nd-18.txt (Neighbor DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) toProposed Standard The IESG has received a request from the IPv6 over Low power WPAN WG (6lowpan) to consider the following document: - 'Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)' draft-ietf-6lowpan-nd-18.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless Personal Area Networks such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non-transitive wireless links. The traditional IPv6 link concept and heavy use of multicast make the protocol inefficient and sometimes impractical in a low power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, addressing mechanisms and duplicate address detection for 6LoWPAN and similar networks. The document, thus updates RFC 4944 to specify the use of the optimizations defined here. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-daboo-webdav-sync-06
Hi Cyrus,
The proposed changes for the two major issues look good to me:
[1] I'm pleased that the concern about adding elements turned out to be a
wording issue.
[2] Your proposed new text is fine - it provides adequate notice/warning about
possible
collection inconsistency, so I'm ok with not providing pseudo-code.
I'll leave the Downref issue ([3]) for you and Peter to work out with the IESG,
and I'm
fine with continued use of your name in the examples if that's common practice.
Thanks,
--David
-Original Message-
From: Cyrus Daboo [mailto:cy...@daboo.name]
Sent: Monday, January 02, 2012 2:44 PM
To: Black, David; arnaud.quill...@oracle.com; gen-...@ietf.org; ietf@ietf.org
Cc: stpe...@stpeter.im
Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06
Hi David,
Thank you for your review. Comments inline:
--On December 27, 2011 11:07:49 PM -0500 david.bl...@emc.com wrote:
[1] -Major- Section 3.5 does not appear to cover the case reporting added
elements on a subsequent synchronization. The problem may be that the
word changed as used in Section 3.5.1 is assumed to cover adding an
element - if so, that's not a good assumption, and the addition case
should be explicitly called out in the title and body of Section 3.5.1.
The first sentence of 3.5.1 is:
A member URL MUST be reported as changed if it has been mapped as a
member of the target collection since the request sync-token was
generated.
The term mapped implies creation/addition of a new resource in this case.
That may not be obvious to anyone who is not intimately familiar with
WebDAV terminology here, so I propose changing that to:
A member URL MUST be reported as changed if it has been newly mapped as
a member of the target collection since the request sync-token was
generated (e.g., when a new resource has been created as a child of the
collection).
[2] -Major- The operations to retrieve changed members of a collection
are not atomic wrt the operation that obtains a report on what has
changed; collection changes can occur between retrieving the report and
retrieving the changed elements or while retrieving the changed elements.
For this reason, simply obtaining a change report and then retrieving the
elements that have changed according to the report may not result in a
consistent (e.g., as of a point in time) copy of a collection. I believe
that this absence of atomicity is a WebDAV feature, as opposed to a
bug, but I believe that this behavior and what to do about it should be
discussed in the draft. I suggest the following, possibly to the end of
section 3.1
i) Add a sentence or two to warn that obtaining a change report and then
retrieving the changed elements may not result in a consistent local
version of the collection if nothing else is done because changes may
have occurred in the interim.
ii Add a discussion of how to ensure that a local copy of the collection
is consistent. The basic idea is to re-presented the sync token for that
copy to the server after the changed elements have been retrieved; the
local copy is consistent if the server reports that there have been no
changes. Some pseudo-code may help, e.g.:
GetSyncCollectionReport(in token, out newtoken, out report);
while (ReportHasChangedItems(report) {
GetChangedItems(report)
token = newtoken;
GetSyncCollectionReport(in token, out newtoken, out report);
}
Actual code should include a counter that counts the number of iterations
of the while loop and exits with an error if the number of iterations
exceeds some limit; that error exit implies that the collection is
(currently) changing too rapidly to obtain a consistent local version.
Good point. I agree that this deserves some additional text to clarify this
situation. However, I would rather not go into too much detail of how
clients re-sync in cases like this as there are a bunch of different ways
that could happen each of which depends on exactly what the client is
trying to do (e.g., in a lot of cases clients will be doing two-way syncs
so will need to reconcile server and local changes within the loop you
propose above - the details of that are not in scope for this
specification). What I propose is the addition of the following paragraph
to the end of Section 3.1:
Typically, a client will use the synchronization report to retrieve the
list of changes, and will follow that with requests to retrieve the
content of changed resources. It is possible that additional changes to
the collection could occur between the time of the synchronization
report and resource content retrieval, which could result in an
inconsistent view of the collection. When clients use this method of
synchronization, they need to be aware that such additional changes
could occur, and track them
primary Paris hotel booking
Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com It's 2012, but the IETF and this hotel chain expects us to book reservations at the main conference hotel by (international) FAX or by *emailing* a form which includes a credit card number so that the hotel can hold the room and implement its relatively bizarre prepay/anti-cancellation policy. Would it be trolling to ask whether anyone verified that cmasson has support for PGP encrypted-email and a proper method of securely storing (and then destroying after use) the several hundred credit card numbers they are about to receive? What person or rate code should we ask for when booking our rooms over the phone? (hey if I'm going old school, I'm doing it all the way!) Though, given the above, I'm relatively worried that my credit card number will simply end up on an unprotected spreadsheet on a PC somewhere in their office even if I call to book. More practically, the hotel blocks at the primary hotel typically fill up quite fast once registration is opened, especially since the overflow hotel is actually more expensive than the primary. Does the hotel fax/call us back to tell us that they have no more rooms available for our requested dates, or is the block open-ended such that they will keep selling rooms in it until the cutoff regardless of the number? Evidently ability to book group rate rooms online is something that should be added to our list of hotel requirements. I'm stunned that it's not there already. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
I agree. In addition to that the pre-pay situation can be a major PITA for expensing purposes. We should add normal booking procedures to the hotel requirements list as well. --Tom On Jan 3, 2012, at 11:52 AM, George, Wes wrote: Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com It's 2012, but the IETF and this hotel chain expects us to book reservations at the main conference hotel by (international) FAX or by *emailing* a form which includes a credit card number so that the hotel can hold the room and implement its relatively bizarre prepay/anti-cancellation policy. Would it be trolling to ask whether anyone verified that cmasson has support for PGP encrypted-email and a proper method of securely storing (and then destroying after use) the several hundred credit card numbers they are about to receive? What person or rate code should we ask for when booking our rooms over the phone? (hey if I'm going old school, I'm doing it all the way!) Though, given the above, I'm relatively worried that my credit card number will simply end up on an unprotected spreadsheet on a PC somewhere in their office even if I call to book. More practically, the hotel blocks at the primary hotel typically fill up quite fast once registration is opened, especially since the overflow hotel is actually more expensive than the primary. Does the hotel fax/call us back to tell us that they have no more rooms available for our requested dates, or is the block open-ended such that they will keep selling rooms in it until the cutoff regardless of the number? Evidently ability to book group rate rooms online is something that should be added to our list of hotel requirements. I'm stunned that it's not there already. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: primary Paris hotel booking
What person or rate code should we ask for when booking our rooms over the phone? (hey if I'm going old school, I'm doing it all the way!) The pdf has a reference number on it. eric ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
--On Tuesday, January 03, 2012 13:57 -0500 Thomas Nadeau tnad...@lucidvision.com wrote: ... I agree. In addition to that the pre-pay situation can be a major PITA for expensing purposes. We should add normal booking procedures to the hotel requirements list as well. It is a little worse than merely a PITA. I've worked for companies who would absolutely forbid making a reservation with a non-refundable deposit more than two months in advance of a meeting unless I was personally willing to assume the risk... and who might treat such a one-day fee as non-reimbursable even if I did stay in the hotel. The good news about Paris is that there is a large supply of hotels in a wide range of qualities and prices and the subway system is comprehensible and works very well.I sort of hate to suggest this, but, if the conditions and/or rates for the IETF-designated hotels don't seem reasonable, go elsewhere (just remember that no one will listen if you don't like the hotel Internet service).One might even speculate that, if a sufficiently large number of people refused to accept the Hotel Concorde's terms and conditions (booking policies, cancellation policies, or something else) and voted by refusing to book there, the IAOC might get the message far more clearly than any number of requests or complaints about what they should negotiate. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
The pre-pay is pretty annoying. And the if you cancel too late, we'll take all your money *really* annoys me. So much so that I booked on-line, direct with the hotel at a higher rate for a nicer room, but still better than the rate for the alternate hotel. And no-prepay and cancel by 4pm the arrival day or pay one day's room. I hate doing it this way - the IETF doesn't get any credit for rooms sold. Mike At 01:57 PM 1/3/2012, Thomas Nadeau wrote: I agree. In addition to that the pre-pay situation can be a major PITA for expensing purposes. We should add normal booking procedures to the hotel requirements list as well. --Tom On Jan 3, 2012, at 11:52 AM, George, Wes wrote: Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com It's 2012, but the IETF and this hotel chain expects us to book reservations at the main conference hotel by (international) FAX or by *emailing* a form which includes a credit card number so that the hotel can hold the room and implement its relatively bizarre prepay/anti-cancellation policy. Would it be trolling to ask whether anyone verified that cmasson has support for PGP encrypted-email and a proper method of securely storing (and then destroying after use) the several hundred credit card numbers they are about to receive? What person or rate code should we ask for when booking our rooms over the phone? (hey if I'm going old school, I'm doing it all the way!) Though, given the above, I'm relatively worried that my credit card number will simply end up on an unprotected spreadsheet on a PC somewhere in their office even if I call to book. More practically, the hotel blocks at the primary hotel typically fill up quite fast once registration is opened, especially since the overflow hotel is actually more expensive than the primary. Does the hotel fax/call us back to tell us that they have no more rooms available for our requested dates, or is the block open-ended such that they will keep selling rooms in it until the cutoff regardless of the number? Evidently ability to book group rate rooms online is something that should be added to our list of hotel requirements. I'm stunned that it's not there already. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: primary Paris hotel booking
One might even speculate that, if a sufficiently large number of people refused to accept the Hotel Concorde's terms and conditions (booking policies, cancellation policies, or something else) and voted by refusing to book there, the IAOC might get the message far more clearly than any number of requests or complaints about what they should negotiate. Much though it pains me to agree with John so early in the year and risk the precedent... +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
Actually (s), the IETF *does* get credit for rooms sold. We reconcile the attendee list with hotel guests. Go for it. On Jan 3, 2012, at 2:48 PM, Michael StJohns wrote: The pre-pay is pretty annoying. And the if you cancel too late, we'll take all your money *really* annoys me. So much so that I booked on-line, direct with the hotel at a higher rate for a nicer room, but still better than the rate for the alternate hotel. And no-prepay and cancel by 4pm the arrival day or pay one day's room. I hate doing it this way - the IETF doesn't get any credit for rooms sold. Mike At 01:57 PM 1/3/2012, Thomas Nadeau wrote: I agree. In addition to that the pre-pay situation can be a major PITA for expensing purposes. We should add normal booking procedures to the hotel requirements list as well. --Tom On Jan 3, 2012, at 11:52 AM, George, Wes wrote: Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com It's 2012, but the IETF and this hotel chain expects us to book reservations at the main conference hotel by (international) FAX or by *emailing* a form which includes a credit card number so that the hotel can hold the room and implement its relatively bizarre prepay/anti-cancellation policy. Would it be trolling to ask whether anyone verified that cmasson has support for PGP encrypted-email and a proper method of securely storing (and then destroying after use) the several hundred credit card numbers they are about to receive? What person or rate code should we ask for when booking our rooms over the phone? (hey if I'm going old school, I'm doing it all the way!) Though, given the above, I'm relatively worried that my credit card number will simply end up on an unprotected spreadsheet on a PC somewhere in their office even if I call to book. More practically, the hotel blocks at the primary hotel typically fill up quite fast once registration is opened, especially since the overflow hotel is actually more expensive than the primary. Does the hotel fax/call us back to tell us that they have no more rooms available for our requested dates, or is the block open-ended such that they will keep selling rooms in it until the cutoff regardless of the number? Evidently ability to book group rate rooms online is something that should be added to our list of hotel requirements. I'm stunned that it's not there already. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
On 01/03/2012 08:52 AM, George, Wes wrote: Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com I crossed my fingers and clicked 'send' of the PDF with my credit card number in it. I didn't pay enough attention to the no-refund policy. :-( I emailed my reservation on 12/22 and got a confirmation email on 12/26. So far, my credit card has not been charged anything. I think there should always be a full-refund cut-off date for the IETF hotel, even if it is 2 months in advance. I thought the cut-off was 15 days, but that is just for 2 more nights billed in advance, not the first night. Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
--On Tuesday, January 03, 2012 15:54 -0500 Eric Burger ebur...@standardstrack.com wrote: Actually (s), the IETF *does* get credit for rooms sold. We reconcile the attendee list with hotel guests. Go for it. In a way, that is really too bad. If people find the cancellation or other) policies problematic enough to actually change their behavior (as distinct from whining), it would be good for the IAOC to get that message in a way that was clear and couldn't be avoided. If you don't incur a penalty for failure to fill a block and/or can't really tell paid a higher rate to get a better policy from reserved after the block was full or past the deadline, then there are few, if any, incentives for telling a hotel that these sort of policies won't do. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
On 2012-01-04 10:03, John C Klensin wrote: --On Tuesday, January 03, 2012 15:54 -0500 Eric Burger ebur...@standardstrack.com wrote: Actually (s), the IETF *does* get credit for rooms sold. We reconcile the attendee list with hotel guests. Go for it. In a way, that is really too bad. If people find the cancellation or other) policies problematic enough to actually change their behavior (as distinct from whining), it would be good for the IAOC to get that message in a way that was clear and couldn't be avoided. If you don't incur a penalty for failure to fill a block and/or can't really tell paid a higher rate to get a better policy from reserved after the block was full or past the deadline, then there are few, if any, incentives for telling a hotel that these sort of policies won't do. There's a third case, paid a lower rate than the conference rate (usually due to a smart corporate travel agent). I've never understood why conferences don't get a corporate-equivalent rate. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
I do not know why hotels will not put it into a contract; believe me we try. I call this the double-secret discount. It would be nice if the hotels gave us Most Favored Nation status, but since they do not, and no hotel has, this is the next best thing. On Jan 3, 2012, at 4:35 PM, Brian E Carpenter wrote: On 2012-01-04 10:03, John C Klensin wrote: --On Tuesday, January 03, 2012 15:54 -0500 Eric Burger ebur...@standardstrack.com wrote: Actually (s), the IETF *does* get credit for rooms sold. We reconcile the attendee list with hotel guests. Go for it. In a way, that is really too bad. If people find the cancellation or other) policies problematic enough to actually change their behavior (as distinct from whining), it would be good for the IAOC to get that message in a way that was clear and couldn't be avoided. If you don't incur a penalty for failure to fill a block and/or can't really tell paid a higher rate to get a better policy from reserved after the block was full or past the deadline, then there are few, if any, incentives for telling a hotel that these sort of policies won't do. There's a third case, paid a lower rate than the conference rate (usually due to a smart corporate travel agent). I've never understood why conferences don't get a corporate-equivalent rate. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
hat type='AD'/ On 1/2/12 12:36 AM, Mykyta Yevstifeyev wrote: While that was me who proposed the change to semantics, I tend more and more to agree with documenting the existing practice; but let's wait a response from W3C community first to see what's their attitude towards the proposal. Mykyta, You have not yet submitted a revised I-D. Currently the document under consideration is draft-yevstifeyev-disclosure-relation-00. If you want to make fundamental changes to the spec, please do so by submitting a revised I-D. In the meantime, I have deferred the document to the January 19 telechat while you decide how you want to proceed. If you decide that you want to define two link relations instead of one, you will need to submit a revised I-D, which will need to undergo another review on the link-relati...@ietf.org list and then another IETF Last Call. There is no need to waste IESG and general IETF attention on this specification if the author can't make up his mind about his own intentions. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
http://franceforrent.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
On Tue, Jan 3, 2012 at 4:01 PM, Andy Bierman a...@netconfcentral.org wrote: On 01/03/2012 08:52 AM, George, Wes wrote: Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com I crossed my fingers and clicked 'send' of the PDF with my credit card number in it. I didn't pay enough attention to the no-refund policy. :-( I emailed my reservation on 12/22 and got a confirmation email on 12/26. So far, my credit card has not been charged anything. I think there should always be a full-refund cut-off date for the IETF hotel, even if it is 2 months in advance. I thought the cut-off was 15 days, but that is just for 2 more nights billed in advance, not the first night. Actually, that's unclear. I've read the form several times. It says you lose any non-refudable deposit. And it says the two-day charge is non-refundable. But it never says that the initial one-day charge is non-refundable... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] primary Paris hotel booking
Wes, I think everyone on the IAOC was surprised when we first heard that the meeting hotel insisted that people can only use fax or email to send in their reservations. We tried to get the hotel to change this, but they would not budge. This included their rejection of accepting reservations by phone. Other nearby hotels were much more expensive, so this reservation method was reluctantly accepted. You are, of course, free to book online but when I checked earlier today the rates were higher even without breakfast included (but the cancelation policy less was severe). Your tradeoff. In this venue, the IETF will receive credit for your stay if you book on line (or through your corporate travel department). It also most goes with out saying that there are also many other hotels in Paris at lower and higher rates. Bob On Jan 3, 2012, at 8:52 AM, George, Wes wrote: Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com It's 2012, but the IETF and this hotel chain expects us to book reservations at the main conference hotel by (international) FAX or by *emailing* a form which includes a credit card number so that the hotel can hold the room and implement its relatively bizarre prepay/anti-cancellation policy. Would it be trolling to ask whether anyone verified that cmasson has support for PGP encrypted-email and a proper method of securely storing (and then destroying after use) the several hundred credit card numbers they are about to receive? What person or rate code should we ask for when booking our rooms over the phone? (hey if I'm going old school, I'm doing it all the way!) Though, given the above, I'm relatively worried that my credit card number will simply end up on an unprotected spreadsheet on a PC somewhere in their office even if I call to book. More practically, the hotel blocks at the primary hotel typically fill up quite fast once registration is opened, especially since the overflow hotel is actually more expensive than the primary. Does the hotel fax/call us back to tell us that they have no more rooms available for our requested dates, or is the block open-ended such that they will keep selling rooms in it until the cutoff regardless of the number? Evidently ability to book group rate rooms online is something that should be added to our list of hotel requirements. I'm stunned that it's not there already. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ IAOC mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/iaoc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Definition
Hi, Can someone please explain me the term Protocol. Does it also mean it has some software code underlying beneath it. Please help me understand. Regards, Kaushal ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
In very simple terms: A protocol is a set of rules for interaction. In this case the interaction is between computers. This can involve both hardware and software and protocols define the interactions as well as the formats (bits on the wire etc). For a much more comprehensive definition, see: http://en.wikipedia.org/wiki/Communications_protocol Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Wed, 4 Jan 2012, Kaushal Shriyan wrote: Hi, Can someone please explain me the term Protocol. Does it also mean it has some software code underlying beneath it. Please help me understand. Regards, Kaushal ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
--On Monday, January 02, 2012 09:36 +0200 Mykyta Yevstifeyev evniki...@gmail.com wrote: ... I believe that the IESG ought to take exceptional care with individual submissions, precisely because they are published in the IETF stream, requiring significant expertise or careful reading to determine whether they actually represent informed and competent IETF consensus. Against that test, this document is not ready for approval and RFC publication. Specific examples: (1) The second sentence of the Introduction begins This document specifies a new type of such relationship But this is not new: it has been around for years, as the next paragraph (and comments on the IETF list) indicate. It's new in context of being formally registered. Then say that it specifies a registration for something that has been around for a while, not that it is new. (2) The last paragraph of the Introduction reads: This document is to formally register the 'disclosure' Link Relation Type with IANA and provide a permanent record on it for the Internet community. Additionally, it expands the sphere of this relation type to allow its use when referring to separate patent disclosures. So it registers the type (good, IMO); makes a permanent and public record --which the author believes W3C has failed to do (good, IMO); documents the existing practice (also good, IMO); and creates an untested extension (outside the scope of Informational publication of an existing practice, IMO). So do you propose dropping the semantics for separate disclosures and leaving the original W3C's? I propose that you figure out what you want to do, that you be very explicit about what (if anything) is new and what is existing practice, and that you get out a new I-D that says whatever you intend. If you are asking me the substantive question, I think that, if you are going to propose an extension, you are obligated to be very clear what the extension is and to do a careful review of what issues might arise with it. I'm not sure I have an opinion about whether the extension is a good idea -- I need that information to figure it out and I think it is your obligation to supply it. I think what I'm saying here is consistent in general principles, if not in detail, with Peter's recent note -- making what you are proposing clear is your responsibility. Please don't ask the community to spend time on review until you have a very specific and clear proposal with which you are satisfied. ... (4) While it is not unusual for Acknowledgments sections to be updated during or after Last Call, an entry of TBD for the only contributors to the document make it impossible for the community to verify that the BCP78 requirements have been followed. TBD occurred because there were no comments received before LC; but now, I hope, this may be corrected. Then get a new I-D posted (see Peter's note). I think this document could be cleaned up and made ready for publication by using any of the following three options: ... (iii) Modify this document to be _extremely_ clear about what is existing practice and what is the author's suggestion about an extension. For the latter, the change being made, the justification for it, and a risk analysis should be present and explicit. While that was me who proposed the change to semantics, I tend more and more to agree with documenting the existing practice; but let's wait a response from W3C community first to see what's their attitude towards the proposal. Documenting the existing spec would work for me (but so would doing so and adding a well-vetted and well-documented extension). I do suggest that you not wait for a response from W3C but that you try to actively engage with them, seeking help from Thomas, Julian, Mark, or others as appropriate. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt - update
So I've submitted the revised version, taking into account all the LC comments, and the consensus on defining W3C's current practice (as I see many comments received with this respect) rather than two separate relation types. A number of other edits have been made; you may see the diffs at http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-disclosure-relation-01 and the draft at tools.ietf.org/html/draft-yevstifeyev-disclosure-relation-01. Meanwhile, as the document is deferred to next IESG telechat, you may freely submit your comments on this version, either publicly or privately to the author. Mykyta Yevstifeyev 2012/1/4 Peter Saint-Andre stpe...@stpeter.im: hat type='AD'/ On 1/2/12 12:36 AM, Mykyta Yevstifeyev wrote: While that was me who proposed the change to semantics, I tend more and more to agree with documenting the existing practice; but let's wait a response from W3C community first to see what's their attitude towards the proposal. Mykyta, You have not yet submitted a revised I-D. Currently the document under consideration is draft-yevstifeyev-disclosure-relation-00. If you want to make fundamental changes to the spec, please do so by submitting a revised I-D. In the meantime, I have deferred the document to the January 19 telechat while you decide how you want to proceed. If you decide that you want to define two link relations instead of one, you will need to submit a revised I-D, which will need to undergo another review on the link-relati...@ietf.org list and then another IETF Last Call. There is no need to waste IESG and general IETF attention on this specification if the author can't make up his mind about his own intentions. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-netext-bulk-re-registration-09.txt (Bulk Binding Update Support for Proxy Mobile IPv6) to Proposed Standard
The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Bulk Binding Update Support for Proxy Mobile IPv6' draft-ietf-netext-bulk-re-registration-09.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-01-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines an optimization to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope with the use of a group identifier. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-bulk-re-registration/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-bulk-re-registration/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-mile-rfc6046-bis-05.txt (Transport of Real-time Inter-network Defense (RID) Messages over HTTP/ TLS) to Proposed Standard
The IESG has received a request from the Managed Incident Lightweight Exchange WG (mile) to consider the following document: - 'Transport of Real-time Inter-network Defense (RID) Messages over HTTP/ TLS' draft-ietf-mile-rfc6046-bis-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-01-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Realtime Internetwork Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6046-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6046-bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
