Fred,
On 2012-03-22 13:29, Fred Baker wrote:
> On Mar 21, 2012, at 10:51 PM, Brian E Carpenter wrote:
>> In other words if the IETF doesn't define the zone index, every
>> implementor will have to do so anyway. Also, read the last clause
>> carefully: it says the stack MUST allow OPTIONAL use of t
OMA IETF MIF API Workshop
Time: Tuesday: 18:10-20:00
Location: TBD
1) Program
1.1) OMA OpenCMAPI activity (Thierry)
1.2) IETF MIF API Design (Ted Lemon)
1.3) IETF API related work (TBD)
1.4) OMA API Program (OMA Member)
1.5) Vendor's today implementation (Maybe)
1.6) Next step between IETF and OM
I don’t see a problem with the IETF process. We should however understand why
the ITU-T process failed to reach a consensus or approval.
Draft-betts states “A number of experts in the IETF do not consider that the
development or deployment of a second protocol solution within the same
archite
On Mar 21, 2012, at 10:51 PM, Brian E Carpenter wrote:
> In other words if the IETF doesn't define the zone index, every
> implementor will have to do so anyway. Also, read the last clause
> carefully: it says the stack MUST allow OPTIONAL use of the zone
> index internally.
Implementors generall
If you have attended any IETF meetings in the last several years you
will have noticed two publications available from the registration
desk or literature table:
* The IETF Journal, published by the Internet Society
http://www.internetsociety.org/ietfjournal
and
* The Internet Protocol Jou
IESG,
I do *NOT* support this draft unless the following changes are made:
The first paragraph of section 8 Acknowledgements has to be removed:
It is an attempt to capture history, but lacks accuracy.
Removal does not impact the technical information in the draft;
the tools have evolved signific
I support the allocation of an ACH codepoint to G.8113.1, not precluding the
ITU-T to progress refinements to the protocol following its own process.
As indicated by Russ, this approach "creates a situation where G.8113.1
succeeded or fails based on the ITU-T members actions, with no finger poin
On 2012-03-22 09:43, Fred Baker wrote:
> On Mar 19, 2012, at 11:55 AM, Sabahattin Gucukoglu wrote:
>
>> I've obviously not been doing all my homework, and RFC 4007 slipped my
>> attention. Worse, for all the communication my IPv6 nodes are doing amongst
>> themselves using link-local addresses,
Yes/Support.
I also support the following comment from Mr.Tom Petch.
"There is no reason not to approve the allocation of a code point
and furthermore, I believe we should do it now, to facilitate the
migration of the existing boxes to an approved solution."
It is very difficult for me to fin
On Mar 19, 2012, at 11:55 AM, Sabahattin Gucukoglu wrote:
> I've obviously not been doing all my homework, and RFC 4007 slipped my
> attention. Worse, for all the communication my IPv6 nodes are doing amongst
> themselves using link-local addresses, it's never really been much more than
> a h
Nurit,
Section 2 “Scope of the Ethernet based OAM ACH Type” contains the
following text:
"The code point allocated by this document is intended to be used only for
Ethernet based OAM messages, defined in the ITU-T Recommendation
[G.8113.1], carried in the G-ACh . These Ethernet based OAM messa
All,
Two points to consider:
1) Below it is stated:
"In the future, all codepoint allocations to the ITU-T should be tied to
one specific, dated revision of their specification only. This is similar
to the ITU-T's own processes, such as section 2.2.1 of Rec. A.5, which
requires a version numb
Loa,
Thank you for your comments and suggestions, please see in line below.
Regards,
Malcolm
ietf-boun...@ietf.org wrote on 12/03/2012 04:31:43 AM:
> Loa Andersson
> Sent by: ietf-boun...@ietf.org
>
> 12/03/2012 04:31 AM
>
> To
>
> ietf@ietf.org
>
> cc
>
> Subject
>
> Re: [PWE3] FW: L
On Wed, Mar 21, 2012 at 12:57 PM, Worley, Dale R (Dale)
wrote:
>> From: Craig Finseth [snar...@gmail.com]
>>
>> You've just rediscovered what the "link local" part of the link-local
>> address means: the address is local to the link! It is not globally
>> unique or even unique within a host, it i
> My reading of question 7 is
> that the document shepherd have to ask the authors to confirm the IPR
> status to their knowledge which is different than just reporting what was
> discussed in the WG and which IP statements were submitted. Did I
> mis-understand question 7.
You're correct: questi
Hi Barry,
I read your response and it is OK as long as the Shephard has to respond to
question 8 and inform what happened in the WG. My reading of question 7 is
that the document shepherd have to ask the authors to confirm the IPR
status to their knowledge which is different than just reporting wh
Stephan Wenger writes:
>(1) Are you aware of any IPR that applies to ?
> (2) If so,
>has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
> 3979,
>4879, 3669 and 5378 for more details)?
>
>
> For the majority of the documents I am working on, the answer to question
[I am removing the avt and payload WG lists from this, so they can
keep at their work; feel free to direct people from those lists to the
IETF discussion list. And thanks for moving this to the right lists.]
Hi, Stephan.
I think we're mostly in agreement, then, judging from what you say.
The gap
Hi Barry,
Adding the IPRWG and ietf@ietf.
For the benefit if "new" readers: This is about an updated proto shepherd
writeup template, asking two questions about IPR that, IMO may not be in
compliance with the IETF's IPR policy.
I was not aware that the proto template had IESG blessing. Still, I
> From: Craig Finseth [snar...@gmail.com]
>
> You've just rediscovered what the "link local" part of the link-local
> address means: the address is local to the link! It is not globally
> unique or even unique within a host, it is just unique within a link.
Actually, it's globally *unique*, beca
On Wed, Mar 21, 2012 at 12:44 PM, Worley, Dale R (Dale)
wrote:
> OK, I know nothing about the subject, but when I do "ifconfig" I get:
>
> eth0 Link encap:Ethernet HWaddr 00:16:35:AF:82:03
> inet addr:135.55.22.90 Bcast:135.55.22.255 Mask:255.255.255.0
> inet6
> From: Sabahattin Gucukoglu [m...@sabahattin-gucukoglu.com]
>
> [...] when I ping one from the other using link-local-scoped
> addresses, I have to put in this zone identifier (%ifname on BSD and
> Linux).
> [...]
> Can't it figure it out itself?
OK, I know nothing about the subject, but when I
Considering that the need for this code point is a result of the ITU
not fully complying with the IETF agreement, I cannot agree that we
should simply allocate a code point for whatever the ITU wants to do
in the future.
It seems the best of the options to allocate a code point (much better
than s
Dear all,
Wrt draft-betts, I believe it is appropriate to allocate a code point for the
referenced specification without any restriction about the possibility to
evolve messages/protocols when compatibility is preserved. It is not only
unnecessary but it does not help in improving the relationsh
Dear all,
Wrt draft-betts, I believe it is appropriate to allocate a code point for the
referenced specification without any restriction about the possibility to
evolve messages/protocols when compatibility is preserved. It is not only
unnecessary but it does not help in improving the relationsh
I support the draft.
Multi-vendor interoperable implementations of the protocol the draft is asking
for the allocation of a code point has been already tested and deployed and
therefore I agree with Mr. Petch when he says we should approve it now to
facilitate the migration of the existing bo
I support the allocation of an ACH code point to G.8113.1, and I agree with
Russ's comment.
In addition, to avoid the same argument after the ITU-T's decision, I suggest
we should clearly conclude that a code point be
available if ITU-T will make consensus on G.8113.1, during this last call.
Thi
Tom,
I've let this sit a while, but wanted to respond on the following point:
On 3/6/12 4:25 PM, t.petch wrote:
> -ur responsibility is to ourselves first and foremost, and to see that
> our process is followed. That process exists to, amongst other things,
> insure safe use and interoperable us
Hi,
On 03/21/2012 09:20 AM, Satoshi UENO wrote:
Hi,
I support to allocate a codepoint to G.8113.1.
Good for you. But just so you and other folks posting
similar mails know, this mail won't be helpful for me
as an AD when it comes to evaluating this topic, since
I've no clue as to the persona
Hi,
I support to allocate a codepoint to G.8113.1.
Best ragards,
Satoshi
Hello,
I still expect the author of draft-betts to answer my question...
"Maybe you could clarify how the text in your draft can be improved to
protect the use of the code point from future extensions beyond the purpose of
the code point allocation?"
I am a bit disappointed to see that th
31 matches
Mail list logo
