Subject: Re: [MMUSIC] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34

From: Magnus Westerlund <[email-masked]>
Date: Fri, 7 Jun 2013 11:35:23 +0200

Hi Elwyn,

Many thanks for the detailed review. We will address the nits you have
raised, but I cut them out of this reply to focus on the more
substantial issues you have brought up.

See inline below.

On 2013-06-06 02:11, Elwyn Davies wrote:
> I am an additional Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-mmusic-rfc2326bis
> Reviewer: Elwyn Davies
> Review Date: 5 June 2013
> IETF LC End Date: 5 JUne 2013
> IESG Telechat date: (if known) -
> 
> Summary:
> Almost ready.  Generally this is an excellent and well written document,
> particularly given its size.  There are a few minor issues to sort out
> mainly at the nit level and some consistency issues to fix up.  The two
> issues that I have brought out below are really at what the IESG would
> call 'DISCUSS-DISCUSS' level.  The issue of URI scheme redefinition may
> well have already been cleared by the URI expert - the draft does not do
> itself any favours here by failing to explain what the syntax changes
> are in s4.2; this raises immediate red flags that only start to fade a
> couple of hundred pages later. The rudimentary nature of the pipeline
> mechanism is carried over from RTSP 1.0.  I'd like to be sure that this
> has been properly discussed in the WG as it looks pretty flaky to an
> outsider.  There are several inconsistencies between various lists of
> headers that need sorting out and there is no definition of
> Proxy-Authorization in the ABNF.
> 
> There are also a fairly large number of editorial nits but these are all
> localized and trivial to fix.  Finally I have't had time to review the
> appendices (maybe there will be a follow up).
> 
> Robert Sparks is the main gen-art reviewer for the document; he asked
> for additional eyes on the document given the size and his RAI
> background.  Having (just) seen his review, I think we have both picked
> up on the URI scheme and pipeline issues.  I am not sure that I concur
> with his view that there is significant normative material in the
> appendices - AFAICS the main protocol definition *is* in the main body
> of the document and the bits especiially in Appendices B and C are not
> the core of the protocol.  However this is based on a very cursory
> glance through something like 75 pages of the document.  However, I do
> concur with Robert's view that it needs a security expert to check the
> security stories.
> 
> Major(ish) issues:
> s4.2: This section (re-)defines the URI schemes "rtsp" and "rtsps". The 
> last sentence of para 1 states that the 'details of the syntax' of the 
> URIs 'have been changed'.  Is this a reasonable thing to do? Has this 
> been cleared with the URI expert reviewer?  I am not entirely clear what 
> the change involves and the draft doesn't explain exactly how the syntax 
> has been altered  and its consequences (if any) in s4.2.  Some details
> are finally given in s22.14.

These syntax changes where discussed in the reviews I got on the URI
list. That resulted in the explicitness in the template, but I forgot
about adding anything into Section 4.2. I see no issue with adding the
following clarification to Section 4.2:

   The details of the syntax of "rtsp" and "rtsps" URIs has been changed
   from RTSP 1.0.  These changes are:

   o  Support for IPV6 literal in host part and future IP literals
      through RFC 3986 defined mechanism.

   o  A new relative format to use in the RTSP protocol elements that is
      not required to start with "/".

   Neither should have any significant impact on interoperability.  If
   one is required to use IPv6 literals to reach an RTSP server, then
   that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully
   IPv6 capable protocol.  Thus, RTSP 2.0 support will be needed anyway.
   The second change will only occur in RTSP messages, that are
   explicitly identified as being RTSP 2.0 messages, thus a RTSP 1.0
   only agent will not be required to parse this variant.

I hope this makes it clear that these syntax changes is unlikely to hurt
the interoperability.

> 
> 
> Minor issues:
> s11, para 3: I guess that the WG decided that sticking with the RTSP 1.0
> model of sending requests and worrying about success of prior prior
> pipelined requests was the right answer.  I would have thought that it
> might have been helpful to provide qualifiers on the Pipelined-Requests
> header that allowed subsequent requests to be suppressed unless the
> previous command resulted in one of a given set of status codes with a
> 'reset' option to 'restart' the pipeline.  It strikes me that this would
> avoid some irritating need to work out how to recover from arbitrary
> failures in a command chain in a client.
> 

I assume you mean this Section 12 paragraph:

   If a pipelined request builds on the successful completion of one or
   more prior requests the requester must verify that all requests were
   executed as expected.  A common example will be two SETUP requests
   and a PLAY request.  In case one of the SETUP fails unexpectedly, the
   PLAY request can still be successfully executed.  However, the
   resulting presentation will not be as expected by the requesting
   client, as only a single media instead of two will be played.  In
   this case the client can send a PAUSE request, correct the failing
   SETUP request and then request it to be played.

I think I agree with your assessment, that it would have been nice.
However, we should have thought of that when we introduced this type of
pipelining 7 years ago. Making any changes to this at this stage is
counter productive. The reality is that all the "nice" features and
necessary clarifications has been retrofitted into RTSP 1.0 by the ones
that have been using RTSP 1.0. So changing anything will separate the
RTSP 1.0 and RTSP 2.0 implementations. The good thing is that I can't
remember any substantial complaints about this issue.

I hope this resolves your comments.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 7 Jun 2013 16:05:49 +0200

Hi Elwyn,

On 2013-06-07 14:26, Elwyn Davies wrote:
> On Fri, 2013-06-07 at 11:35 +0200, Magnus Westerlund wrote:
>> Hi Elwyn,
>>
> .. and thanks for the quick response.
> 
>>
>> See inline below.
> OK.  I think the responses clear those issues.
> 
> I have done a little bit more on the Appendices and liaised a bit with
> Robert Sparks.  'Highlights':
> 
> Appendix F: I missed that the text/parameter format appeared in the
> examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the
> definitions of these methods what encodings are acceptable for the
> message bodies that may go with these methods and their responses.

Exactly, that is intentional. These methods can use anything that has a
MIME type. Also it has HTTP's mechanisms for determining what formats
one supports.

> Clearly the new text/parameter MIME format is one.  Is it the only one?

It is the only one defined by IETF for this purpose. That is why it is
in the appendix so that RTSP users shall have something to define the
parameters they want in. However, they have to accept the limitations of
a basic text format.

> I guess you could use a application/json or an XML format but I guess
> these would also either have to be called out explicitly in the method
> descriptions or put in as feature extensions.  This needs to be
> clarified in the method descriptions (s13).  The upshot of all this is
> that I think Appendix F needs to be pulled back into Section 20 as
> currently it is the only way to encode the message bodies.

I can agree that the format negotiation for the bodies of
GET/SET_PARAMETER is not clear. I will look at proposing some
improvements of the text related to the handling of method bodies and
their format negotiation.

However, I am not pulling in Appendix F. It is an optional to use format
for parameter value pairs that can be used in these methods, it is not
required. Nor, does the specification define any parameters that are
transferred using this interface. The things that are in the appendix
are not core protocol, they represent either informational things, like
the examples and the state machine. The other appendices are normative
definitions of particular choices for things that can be combined or
used with RTSP, like RTP as media transport.

> 
> Appendix B: I appreciate that the state machine is illustrative and to
> an extent 'abstract'.  However, the tables are really written to
> describe the state machine in the server: the action column mostly
> describes the events that come into the server (apart from the notify
> actions) - sending these 'events' are actions in the client.  The 'real'
> state machine in the both the server and the client has a somewhat more
> complex form: I'd think that there was a STOPPED state in the server
> when the media has reached an end point and not been explictly paused
> and STARTING/PAUSING states in the client while the client waits for
> response to PLAY/PAUSE respectively.  I think a little bit more
> explanation about the dual nature of the columns would solve the
> problem.

There shouldn't be an issue to clarify this nature.

Cheers

Magnus Westerlund

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 07 Jun 2013 13:26:00 +0100

Appendix C: Pending.

Regards,
Elwyn
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 07 Jun 2013 16:40:02 +0100

> their format negotiation.
Good. I don't see where the server tells what formats it accepts for
either GET_PARAMETER or SET_PARAMETER.  Also the Accept spec doesn't say
anything about SET_PARAMETER.  AFAICS the client could tell the server
what formats it accepts as a side-effect of DESCRIBE but that's a bit
arcane - and it is not clear how you would separate the formats for
DESCRIBE from those for GET_PARAM and SET_PARAM.
> used with RTSP, like RTP as media transport.
OK, it is possible to use GET_PARAM for basic requirements without using
message bodies, so you can get away without defining a lowest common
denominator format. However, the use of message bodies for SET_PARAM is
RECOMMENDED so it seems a little odd not to ensure that server and
client will have at least one format in common. (And its not as if we
are dealing with a hugely complicated bit of spec for
text/parameters! :-) ).  Then, given the example in GET_PARAMETER it
seems sensible to advise implementing text/parameters as the default for
GET_PARAM also.

/Elwyn

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Jun 2013 09:52:07 +0200

> DESCRIBE from those for GET_PARAM and SET_PARAM.

Yes, I think this negotiation should happen on per methods basis.
> seems sensible to advise implementing text/parameters as the default for

Sure, I personally don't have any issue with making it at least SHOULD
implement text/parameters. But from my horizon a forward pointer with
the normative requirements is sufficient to accomplish that.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 24 Jun 2013 16:51:46 +0200

Elwyn,

Follow up on some of the nits that is not simply to implement or where I
disagree or want to provide feedback.

This email covers all issues up to and including Section 11. That is as
far as I have managed to process them yet. I will now handle over the
rest of this list to my co-authors.

On 2013-06-06 02:11, Elwyn Davies wrote:
> 
> s2.3, para 5:
>> The server should also regularly send every 5
>>     minutes the current media range in a PLAY_NOTIFY request.
> Shouldn't this be configurable?

As discussed in Section 13.5.2 the reasons for the picked time is the
following:

      The recommendation for sending updates every 5 minutes is due to
      any clock skew issues.  In 5 minutes the clock skew should not
      become too significant as this is not used for media playback and
      synchronization, only for determining which content is available
      to the user.

Yes, it can be configurable, and in fact 5 min is only the recommended
interval. So, if an implementation that have a good reason for something
else can do that. Do you have a reason why you think this should be
configurable?

But, if it should be rewritten, I think the acceptable range for within
to adjust it should be specified, like between 1 min and 2 hours.

> 
> s2.3, last para:
>> If the client waits too long
>>     before resuming the pause point, the content may no longer be
>>     available.  In this case the pause point will be adjusted to the end
>>     of the available media.
> I know this is a subjective choice, but I would have thought adjusting 
> to the beginning of the available media would be what the user expects.
> Later: Having read s13.4.1, I think this conflicts with (or is unclear) 
> compared with s13.4.1, para 2 which states that the pause point will be
> the oldest retained time - that is what I would have expected.

Yes, "end" in the above sentence is not quite right. My proposal is the
following:

In this case the pause point will be adjusted to the closest point in
the available media.

> 
> 
> s3.1, para 3:  Clearly there won't be any smaller type paras in the 
> ASCII version.. is there a PDF version that actually has smaller type?  
> The one I get from the repository doesn't seem to have any smaller type 
> paras.

I removed the "small type" as this is a remains from when the draft was
produced using LaTex and a PDF version was produced.

> 
> s4.4: An external reference to the relevant Society of Motion Picture 
> and Television Engineers standard (probably SMPTE 12M) ought to be 
> included to define things like "SMPTE 30 drop".  [Aside: 29.97 frames 
> per second?? Must be something to do with Never Twice the Same Color.  
> Oh, well,  a little research job for whan I am really bored.]

Yes, it is ST 12M-1 2008 that appears to be the relevant reference. Yes,
SMPTE 30 drop is a NTSC thing.

> 
> s4.9.1: There seems to be some confusion in this section between the
> values from the Seek-Style header and the values from the
> Media-Properties random access property.  The section says the values
> are from Seek-Style but they are actually from the random access
> property.  Presumably there was some intention to interelate the media
> capabilities and the play event policies?  Further this section has
> Random Access, Conditional Random Access, Return to Start and No
> Seeking.  This doesn't match exactly with either Seek-Style (RAP, CoRAP,
> First-Prior and Next) or Media-Properties (Random-Access, Beginning-Only
> and No-Seeking).

Yes, this was confused. Actual the Media-Properties headers values are a
distinct set. Then if doing random access then the Seek-Style policies
applies. This I propose to clarify by writing Section 4.9.1 as:

4.9.1.  Random Access and Seeking

   Random Access is the ability to specify and get media delivered from
   any point inside the content, an operation called seeking.  The
   Media-Properties header will indicate the general capability for a
   media resource to perform random access.  If random access is
   possible the actual behavior policy when seeking can be controlled
   using the Seek-Style header (Section 18.45).

   Random-Access:  The media is seekable to any out of a large number of
      points within the media.  Due to media encoding limitations, a
      particular point may not be reachable, but seeking to a point
      close by is enabled.  A floating point number of seconds may be
      provided to express the worst case distance between random access
      points.

   Beginning-Only:  Seeking is only possible to the beginning of the
      content.

   No-seeking:  Seeking is not possible at all.

> 
> s4.9.x: It would be desirable to use the parameter names in the same 
> form as they appear in s18 (e.g., Random-Access instead of Random 
> Access, No-Seeking instead of No seeking) both in the definitions 
> (s4.9.1 - s4.9.4) and the mapping (s4.9.5).

Yes, that is has been addressed.

> 
> 
> ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified 
> values "smpte", "npt" and "clock" are valid  in the Range parameter.  
> What is the meaning of such an unqualified value?

You are correct about that the basic definition in ABNF allows for
empty. The reason for this is the following stated in Section 18.38:

    It MAY be
   included in GET_PARAMETER requests from the client to the server with
   only a Range format and no value to request the current media
   position, whether the session is in Play or Ready state in the
   included format.

> 
> s5:  It would be sensible to note that the ABNF fragments in s5 and the 
> following sections match with the full syntax productions in s20.

I have added a note, but they are in fact equivalent, but not identical.
Thus I make it clear that that this is for information and the formal is
in section 20.2.2.

> 
> Table 3:  Proxy-Authorization (Section 18.34) doesn't appear in any of 
> the various header categorization tables [I must have better things to 
> do than checking they were all there :-( ].  I think it belongs here.

Sorry, for not having found this myself before. You noticing it missing,
was actually a larger inconsistency issue. It was missing in the ABNF also.

I have spent quite some time now to ensure that the ABNF, the tables in
Section 6-8 and the header description now align as they should
regarding category.

> s8.1.1, code 505:  HTTP code 505 is explicitly '*HTTP* version not 
> supported' - should there really be a separate code for 'RTSP version 
> not supported'?

Yes, but the import of HTTP response codes are their meaning not there
exact definition. Thus 505 is RTSP version not supported as listed in
table. That is also what section 17.5.6 defines it as.

> 
> s9: Is it deliberately left vague as to whether other message types 
> might have message bodies?

This is unnecessary vague. In attempt to clarify this I have proposed
the following rewrite of that paragraph:

The SET_PARAMETER and GET_PARAMETER request and response, and DESCRIBE
response is by this specification defined that they MAY have a message
body and its purpose. All 4xx and 5xx responses MAY also have a message
body to carry additional response information. A message body MAY occur
on any RTSP 2.0 request or response, but the content of the message body
MAY be ignored. Extensions to this specification can specify the purpose
and content of message bodies, including requireing their inclusion.

> 
> s10.2, para 6 and following note:  I can't see that the note following 
> para 6 can be justified: since the restriction on multiple connections 
> from a client to a server is only a SHOULD, an interoperable server MUST 
> be capable of handling multiple connections from a client unless the 
> server can explicitly send back a TOO MANY CONNECTIONS status.

See separate email

> 
> s10.6: RFC 3986 has capability for dealing with IP versions beyond 6... 
> should these be carried over into RTSP?  The IANA registry says they are.

I am uncertain what you want here? Yes, the URI format allows for future
definitions of literal IP address versions. However, RTSP does contain
explicit IPv4 and IPv6 address fields that aren't URIs. Thus, future IP
versions will require some extension definition to function.

> s10.7, para 3: Anti-synchronization measures such as are RECOMMENDED 
> here are usually MANDATORY. (Also applies to wait timer in last para of 
> this section).

Yes, I agree that they usually are. I personally have no issues making
them required. I think the Recommended formulation is really one of
these cases, do this or something even better or you will hang yourself
to be a bit blunt.

But, if I understand you, you think this paragraph should read:

An RTSP server or proxy in an overload situation must select the value
of the Retry-After header carefully and bearing in mind its current load
situation. It is REQUIRED to increase the timeout period in proportion
to the current load on the server, i.e., an increasing workload should
result in an increased length of the indicated unavailability. It is
REQUIRED to not send the same value in the Retry-After header to all
requesting proxies and clients, but to add a variation to the mean value
of the Retry-After header.

Objections to this?

> 
> s10.7, last para: Should the doubling of the wait timer have an upper limit?

Yes, I added an upper limit of 30 minutes. This is way beyond what any
human will accept, only robots will keep on going at this timeout value.
And I think that is large enough to avoid any issues.

I also propose to clarify the range for the variations and added the
classical 0.5 to 1.5 times the deterministic value.

Text proposal.

That timer MUST be doubled for each additional failure to connect or
receive response until the value exceeds 30 minutes when the timers
deterministic value may be set to 30 minutes. It is RECOMMENDED to not
set the same value in the timer for each scheduling, but instead to add
a variation to the mean value, resulting in picking a random value
within the range of 0.5 to 1.5 of the mean value.

> 
> s11, para 4: According to s22.1.3, play.basic, play.scale and play.speed
> are 'defined' in this draft.  The nearest thing to a definition of
> play.basic that I can find is the last sentence of para 4 in this
> section.  I am not convinced that I could produce an interoperable
> implementation of a server with this feature-tag with the one sentence
> 'definition'.  References to where play.xxx are defined would be useful
> (play.scale in s18.44, play.speed in s18.48).
> 

Hmmm, the other feature-tags than play.basic are pretty straightforward
and well contained. play-basic is really a minimal RTSP server
implementation according to the whole spec for media playback.

This can probably be more clearly expressed somewhere, but it can't
really be enumerated. Then we are back to the issue we had with RFC 2326
minimal implementation list that was incomplete and lacked a lot of
things really necessary.

This issue still haven't resulted in any changes to our source.

> s11, Supported (and Proxy-Supported) bullets: 
> OLD:
>          This results in the
>          receiver is learning the requester's feature support.
> NEW:
>          This results in the
>          receiver learning the requester's feature support 
>          relevant to the specified resource.
> [Note: I added 'specified resource' here and then thought about whether
> this made any sense.  It probably needs to be clearer what set of
> features are included in the Supported list for both requester and
> responder.  Are they restricted to those relevant to the specified
> resource that might of course be the whole server, proxy - or client?? -
> in which case there isn't an issue, but it might be a specific
> presentation - what happens then?  Affects s13.1, para 3 also.]

Actually, I don't think it is specific to the media resource. The issue
with making it specific to a media resource is that a RTSP client needs
to be able to look into the future and supply an answer for a media
resource it may not yet know sufficient to provide a tailored response
for. I think it is simpler and better to provide general capabilities in
the supported header and then later determine how well they apply for
the media resource itself.

We do have Media-Properties header to provide more details for what
specific media transformations a server can do when the support play.scale.

Cheers

Magnus Westerlund

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 25 Jun 2013 13:47:46 +0100

Hi, Magnus.

Thanks for the (continuing) responses.

Some comments in line.

I look forward to the updated document!

/Elwyn

> else can do that. Do you have a reason why you think this should be
Standard review reaction to an apparently sensible but arbitrary fixed
parameter!  
> to adjust it should be specified, like between 1 min and 2 hours.

Suggest:
- adding 'approximately' ('send approximately every') and a ref to
s13.5.2 to s2.3. 
- change s13.5.2:
OLD:
   In addition it is
   RECOMMENDED that the server sends these notifications every 5 minutes
   for time-progressing content to ensure the long-term stability of the
   client estimation and allowing for clock skew detection by the
   client. 
NEW:
   In addition it is
   RECOMMENDED that the server sends these notifications approximately 
   every 5 minutes
   for time-progressing content to ensure the long-term stability of the
   client estimation and allowing for clock skew detection by the
   client.  The time between notifications should be greater than 1 minute 
   and less than 2 hours.

> In this case the pause point will be adjusted to the closest point in
Seems like a good choice.
> produced using LaTex and a PDF version was produced.

Fine.

> SMPTE 30 drop is a NTSC thing.

:-)

>    Random Access is the ability to specify and get media delivered 
>    from any point inside the content, an operation called seeking.  The
     ^^^^^^^^^^^^^^^^^^^^^
Try: starting from any time instant within

>    No-seeking:  Seeking is not possible at all.

Generally fine - small suggestion above.

> Yes, that is has been addressed.
OK

>    position, whether the session is in Play or Ready state in the
Two points:
- A suggestion: Make ss4.4/4.5/4.6 into subsections of a new s4.4.  Add
a bit of text in the new s4.4 saying that the range specifiers are used
in the RANGE header and pointing to s18.38 for the unqualified use.
(consistent with s2.7 which gives usage).
- An issue I hadn't spotted: I haven't checked but are the unqualified
values allowed in the SDP extension case (s20.3)?
> Thus I make it clear that that this is for information and the formal is

OK

> was actually a larger inconsistency issue. It was missing in the ABNF also.

(I think I noted that later).

> Section 6-8 and the header description now align as they should

Yes.. tedious job as I found out! Good!

> table. That is also what section 17.5.6 defines it as.

I won't push this one.

> and content of message bodies, including requireing their inclusion.

Seems sensible. Editorial update:
The SET_PARAMETER and GET_PARAMETER requests and responses, and the
DESCRIBE response as defined by this specification MAY have a message
body; the purpose of the message body is defined in each case. All 4xx
and 5xx responses MAY also have a message body to carry additional
response information. Generally a message body MAY be attached to any
RTSP 2.0 request or response, but the content of the message body
MAY be ignored by the receiver. Extensions to this specification can
specify the purpose and content of message bodies, including requiring
their inclusion.
> > server can explicitly send back a TOO MANY CONNECTIONS status.

Should I have had this already?

> versions will require some extension definition to function.

Perhaps an excess of zeal on my behalf.  Perhaps a (non-normative) note
saying what you just wrote: 'Although the general URI format envisages 
potential future new versions of the literal IP address, usage of any
such new version would require other modifications to the RTSP
specofication (e.g., ...[any relevant section(s)]).' 
> of the Retry-After header.

I was only really concerned about the variation.  I would leave the 'how
much to increase' as a RECOMMENDED, but say there MUST be variation in
the retry values sent to different clients if theye are sent at all.

> And I think that is large enough to avoid any issues.

Agreed

> deterministic value may be set to 30 minutes. It is RECOMMENDED to not
  ^^^^^^^^^^^^^
  base?
> This issue still haven't resulted in any changes to our source.

Ah!  I see I have (re-)opened a can of worms!  One thought for providing
the proverbial larger can into which the worms can be stuffed back:

Define 'play.basic' as the default that you get back if none of the
others apply.  How's that for weasel words!
> the media resource itself.

So maybe make it clear that feature support returned is just what the
responder can do generally and is not specific to the URI provided.

Either that or make the request valid only for non-specific URIs (i.e.
at the server/client level) if that is possible (not sure how that would
work for server asking client if that is allowed).
> specific media transformations a server can do when the support play.scale.

Right.

/Elwyn