[Gen-art] gen-art review of draft-ietf-mpls-loss-delay-03

Ready for publication as a proposed standard RFC. That completes my current run of gen-art participation. Please reduce me to 0 per month but don't take me out totally yet, and let's find out what the future brings. There's a chance I'll have time to do more in a few months. Thanks, and see yo

Re: [Gen-art] [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

> -Original Message- > From: pcn-boun...@ietf.org [mailto:pcn-boun...@ietf.org] On Behalf Of > David Harrington > Sent: 22 June 2011 15:10 > To: philip.eard...@bt.com; ruediger.g...@telekom.de; > tom111.tay...@bell.net > Cc: p...@ietf.org; gen-art@ietf.org; elw...@dial.pipex.com > Subject

Re: [Gen-art] [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

Hi Ruediger, Off the top of my head, I would think a signaling approach could provide for a more coordinated response. YMMV. I trust the WG had technical reasons for prefering a feedback signaling approach. I consider the WG to be the experts in this space, so you don't need to convince me, you n

Re: [Gen-art] [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

Hi David, Interoperability would result if no feedback signaling is required. I'm co-author of a draft describing such a solution. Unfortunately the remaining participants of the WG favour signaling based solutions, hence perspectives aren't bright for the draft supported by me. To me, the WG has

Re: [Gen-art] [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

I take your point that ideally there would be an explanation of how to achieve interoperability and that it would have formats, error codes etc specified. I guess this would be a rfc3444 Data Model. Reading your (DH's) latest email, it sounds like you'd need this (rather than what I thought an

Re: [Gen-art] [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

Hi, Let me clear that an abstract information model alone is not likely to satisfy the concern, which is interoperability. > > I think it would be better to specify a mandatory-to-implement > > protocol, or at least a recommended-to-implement protocol, and a > > corresponding data model to ensure

Re: [Gen-art] [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

Hi, The main thing you are missing is an explanation of how you will achieve interoperability. The charter calls for specification of the encoding and transport of the information between points in the system: > > (3) encoding and transport of (pre-)congestion information > > between the interio

Re: [Gen-art] Gen-ART LC Review of draft-ietf-v6ops-6to4-to-historic-04

Ben, splendid comments! I've tried to incorporate all of them, and will either issue a new revision or make the changes during AUTH48 depending on other LC feedback. cheers, Ole > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, > please see the FAQ at >

Re: [Gen-art] [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

Hi all, I agree with Phil regarding the fact that the Information model can be described as an abstract model informally to show the relationships between objects. In particular RFC 3444 mentions: "IMs can be defined in an informal way, using natural languages such as English. An example o

Re: [Gen-art] [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

The CL and SM drafts should definitely specify the information models. In my own mind, the actual protocol specification belongs in another document, since it would be common to the two models. Other edge behaviours (e.g. the piggybacking approach) would require their own protocol solutions.

Re: [Gen-art] [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

Personally I think it unlikely that the WG would ever complete the former The latter might be plausible, though having flicked at 3444 i can't tell exactly what we're missing. It seems to say that an information model is an absrtact model about relationships between objects and can be defined i