Re: [Fecframe] IESG Eval followup: config-signaling anf rtp-raptor

["Rajiv Asati (rajiva)" <rajiva at cisco.com>]

Informational is fine.

Cheers,
Rajiv

> -----Original Message-----
> From: Greg Shepherd [mailto:gjshep at gmail.com]
> Sent: Friday, November 04, 2011 10:30 AM
> To: Rajiv Asati (rajiva); fecframe at ietf.org
> Subject: Fwd: IESG Eval followup: config-signaling anf rtp-raptor
> 
> *,
> 
> There are a few things holding up the config-sig draft, but the one we
> need to help with is:
> 
> MUST this doc progress as experimental, or is there WG consensus to
> move it to informational?
> 
> Please reply promptly to the list.
> 
> Thanks!,
> Greg
> 
> 
> ---------- Forwarded message ----------
> From: David Harrington <ietfdbh at comcast.net>
> Date: Fri, Nov 4, 2011 at 7:23 AM
> Subject: IESG Eval followup: config-signaling anf rtp-raptor
> To: gjshep at gmail.com
> Cc: draft-ietf-fecframe-config-signaling at tools.ietf.org,
> draft-ietf-fecframe-rtp-raptor at tools.ietf.org
> 
> 
> Hi,
> 
> The IESG reviewed the config signaling and rtp-raptor drafts.
> We have work to do.
> 
> config-signaling:
> 1) Can we publish this as Informational?
>        Is that a problem for any cross-SDO work?
>        If this is published as Informational, then compliance is no
> longer appropriate - you don't comply to an Informational document. so
> the RFC2119 keywords should disappear.
> 
> 2) Ask the WG which version of GDOI is supposed to be used? See Sean's
> Comments.
> 
> 3) The document needs a good rewrite, especialy the Abstract and
> Introduction. There are Discusses and Comments from many that the
> document doesn't describe its purpose. This must be clairified.
> 
> 4) There are Discusses and Comments from multiple ADs that must be
> addressed:
> Ron: just remove the reference; I don't know if you want to carry any
> information from that expired mboned doc into this doc.
> Adrian: clarify what is considered a signaling protocol in this doc
> Gonzalo: no RFC2119 keywords in the Introduction (so normative text
> must be moved)
> Jari: internal references (are you using xml2rfc? they have ways to
> keep that in sync for you)
>        clarify how you expect this to be used re: SDP, XML, etc.
> Russ: Gen-ART review
> Sean: "MAY encrypt"
>        MUST is for implementers - see RFC 3365 - unless this is
> Informational.
>        GDOI - explain how to use this. Clarify which version.
> Stephen: "MAY encrypt" => "SHOULD encrypt using PGP or CMS"?
>        GDOI - how to use to manage keys?
> Pete: If Informational, then you can ignore his comment; If
> Experimental, then describe the experiment.
> Robert: new versus copied requirements; point to the existing rules
> rather than copying them here.
>        The #2 comment is critical - are implementers supposed to
> choose from one of these protocols
>        (i.e., these are the only ones allowed in a compliant
> Experimental implementation?)
> 
> rpt-raptor:
> 1) A registration request must be sent to ietf-types at iana.org to
> register the types, per section 5.1 of RFC 4288. The registration
> template needs to be filled in
> 
> 2) There are discusses from Sean, Pete, Robert and Stephen that must
> be addressed, and Comments from Russ (the Gen-ART review) that should
> be addressed in a Revised ID. I think the usage of RFC2119 keywords is
> acceptable, but might be improved. Please read and **consider** Pete's
> comments on RFC2119 usage, and then do what you think is right.
> 
> Please get these Revised IDs done asap so I can send them off to the
> RFC Editor.
> 
> David Harrington
> Director, IETF Transport Area
> ietfdbh at comcast.net (preferred for ietf)
> dbharrington at huaweisymantec.com
> +1 603 828 1401 (cell)