Subject: [MBONED] [Fwd: Re: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"]]

From: Hiroaki Sato <[email-masked]>
Date: Tue, 15 Jul 2008 11:06:08 +0900

Hi all,

I was sending a following response to DIME-ML.
I missed CC to MBONED-ML, so forward it.

Jouni,

Thank you for your feedback.  We just released a new version of
ietf-mboned-multiaaa-framework including many of your suggestions.

Responses inline:

<snip>
>
> Some editorial comments:
>
> Section 1.1
>
>  o "...communication schemes of any kind, such as 1-to-n (case of
>    TV broadcasting services for example) or n-to-p (case of..."
>
>    rather use  one-to-many and many-to-many

Changed as recommended.

>  o "...high-quality multicast transport using a Resource and
>    Admission Control System (RACS) with multicast..."
>
>    I assume this refers to TiSPAN defined RACS functional entity.
>    I would like to see a reference here.

We no longer refer to RACS. Now using a general word "MACF".

>  o "...presented in draft-ietf-mboned-maccnt-req-04.txt,..."
>
>    Rather use the reference to [1]
>  o "...MACCNT-REQ-draft describes the requirements in CDN services
>    using IP multicast[1]. The requirements are derived from:..."
>  o "...Detailed requirements are presented in MACCNT-REQ-draft...."
>
>    Again the reference..

Changed reference style throughout. eg. [I-D.mboned-maccnt-req]

> Section 2.1
>
>  o "   Note: The definition of a receiver (device) and a user
>    (human) should not be confused. "
>
>    This note does not really fit into definitions as it is. Now it
>    looks like yet another definition, which is not the intent I
>    assume.

Combined into the definition.

> Section 2.2
>
>  o AAA, mAAA, NSP-AAA, CP-AAA, ID, API, IF, NAS, QoS
>    and RACS are missing

Added (except RACS which no longer is in the draft.)

> Section 3
>
>  o "...are divided between separate entities.  The MACCNT-REQ-
>    draft provides more detail of the multiple versus single..."

Added reference.

>  o "...entity CDS network models. "
>
>    Expand CDS on the first use

Done.

>  o "As such it should not be assumed that the entity
>    responsible for the multicasting structure and the entity
>    responsible for content serving are the same.  Indeed
>    because the infrastructure for multicasting is expensive
>    and many content holders are not likely to be competent at
>    building and maintaining complicated infrastructures
>    necessary for multicasting, many content holders would
>    prefer to purchase transport and management services from a
>    network service provider and thus share the infrastructure
>    costs with other content holders."
>
>    Consider revising.. to something like.. whatever..
>
>    "It should not be assumed that the entity  responsible for
>     the multicasting infrastructure is not the same as the entity
>     responsible for serving the content. Content holders are not
>     likely to build and maintain their own multicast network
>     infrastructure that is not part of their expertise area. Rather
>     they are willing to purchase transport and management services
>     from dedicated network service providers."'
Combined and shortened the two paragraphs to:

"In many cases however the content provision and network provision roles
are divided between separate entities. Commonly, Content Providers (CP)
do not build and maintain their own multicast network infrastructure as
that is not part of their expertise area. Rather CP often opt to
purchase transport and management services from dedicated network
service providers. "
>  o "...The use model of a single NSP providing multicasting
>    services to multiple CPs the following general requirements
>    from MACCNT-REQ-draft apply:..."
>
>    References..
>
>    Expand CP on the first usage.

Done

>    Reword to something like
>
>    "In the usage model of where a single NSP provides multicast
>     services to multiple Content Providers (CP), the following
>     general requirements from [1] apply:.."

Changed to:
In the usage model of where a single NSP provides multicast services to
multiple CPs, the following general requirements from
[I-D.mboned-maccnt-req] apply:

>  o "When the NSP and CP are the same single entity the general
>    requirements are as follows."
>
>    revise to
>
>    "When the NSP and the CP are the same entity then the general
>     requirements are as follows:"

Done.

> Section 4.1
>
>  o "A general high-level framework can be represented as
>    follows."
>
>    revise to.. something like
>
>    "A general high-level framework is presented in the
>     Figure 1."

Done

>  o For relationships use similar style as in previous sections.
>    e.g. 1:1 -> one-to-one or 1-to-1 etc..

Done

>  o Expand STB on the first use.
>
>  o What is STB? It is mentioned only once in this document in this
>    section..

STB section was removed in version 6 so no longer relevant.

>  o "The CP is responsible for Authentication and Authorization.."
>
>    use "authentication and authorization"

Done.

>  o "...(authentication by proxy), and the NSP's relevant AAA.."
>
>    Authentication via or through?
The relevant sentence was removed in version 6
>  o NSP-AAA and CP-AAA?
>
>  o "...without querying the CP-AAA.  When the NSP cannot or
>    decides not to multicast to users, the NSP may notify the..."
>
>    I don't get what this is supposed to mean.

We believe the wording as of v6 addresses the above concern.
"When the CP cannot (e.g. error or resource issues) or decides not (e.g.
policy issues) to deliver content, the CP is responsible for notifying
the NSP of the reason.  It is up to the NSP how to relay or translate
the reasons for rejection to the user."

> Section 4.2
>
>  o Heading -> "Multiple User Identities"
>
>  o Expand ID on the first use.

Done

> Section 4.2
>
>  o References to [1].. and a consistent way of doing those would be
> nice.
>
>  o Reference to RFC3810 & RFC3376
no longer explicitly referenced.
>  o Expand API on the first use

API removed from draft as of version 6.

> Section 4.5
>
>  o References
>
> Section 4.7
>
>  o "reestablish" to "re-establish"?

Relevant section deleted as of version 6.

> Section 5
>
>  o "Section 3.1 introduces the high-level AAA framework for..."
>
>     introduced

Done

>  o "...access to the User.  First a user that requests content..."
>
>    revise to.. something like
>
>    "...access to a user. First the user.."

Done

>  o "...to the appropriate CP for Authentication and Authorization..."
>
>    authorization and authorization

Done

>  o Notation of relations.. 1:1 etc to similar as previously used
>
> Section 5.2
>
>  o References..
>
>  o Should these "well managed", "fully enabled AAA" etc be defined
>    in section 2.1
>
>  o "Section 3.1 intriduces" -> introduced
>

these are removed in the current version.

>  o "of a AAA" -> "of an AAA"
it is generally read "Triple-A" so will leave as a
>  o In the figure 2 the caption is partial.. or parts of it is
>    before the figure.. should be fixed
Changed caption formatting.
>  o Use consistent way of expanding abbreviations.. both types e.g.
>    Content Provider (CP) and CP (Content Provider) are used

Not sure where this is referring to NP and NSP wording inconsistency was
fixed in a prior version.

>  o Figure 3 has similar caption issues as figure 2

Changed caption formatting.

> I got a bit stuck to general presentation of the draft. It needs
> more work. For general readability of the draft I would suggest
> paying attention to overall formatting. This may sound naive but
> IMHO I would suggest using some tool that generates automatically
> a proper layout, such as xml2rfc.
>
>
> And then some remotely technical comments, if any.
>
>  o It is rather unclear to me how the actual AAA transactions are
>    supposed to work (refer to fig. 1). CP auth/authz the user
>    and the CP also auth/authz the NSP?  Are these separate?
>    What about user to NSP auth/authz? (this is then later
>    described better in section 5.1 but not where the fig.1
>    is described)

We removed mention of the messages in Figure 1 and added a new Figure 2
to 5.1 Basic Connection Model that includes the messages.

>  o "The actual mapping rules for NSPs and CPs to map user IDs
>    with the IDs in other provider domains is a matter for the
>    providers.  A solution should provide an API between the
>    providers to flexibly support various mapping methods."

The API discussion part was removed.

>    The inter-working could be explained a bit more carefully.
>    An example would be nice. Otherwise this is rather unambiguous.
>
>
>  o Standardization of logs? Do you mean coming up with a file
>    presentation format for user session tracking? Or rather
>    just defining that billing record format? Could any of the
>    existing ones be re-used or expanded?

Believe this was removed in a previous version. Instead the draft
discusses "accounting report messages" sent by NSP to CP discussed in
section 4.3.

>  o "...This framework specifies an accounting API provided by the
>    NSP and accessed by the CP to allow for sharing user-..."
>
>    I don't really find the API specification in this framework
>    draft

The discussion of API was removed in a subsequent version after you
reviewed.

>  o Does API here actually mean AAA interface or something else?
>    The use of API-term is somewhat confusing..
The discussion of API was removed in a subsequent version
>  o "content request" is AAA request?
>

No it is a request for a multicast channel.

>  o It would be nice to have a separate sections (or something)
>    going through each AAA interface (IFa, IFb, etc)

We added titles above paragraphs and broke large paragraphs into smaller
paragraphs as appropriate.

Thanks

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

-- 
************************************
NTT Network Service Systems Lab.
Hiroaki Sato
TEL:0422-59-4683 (+81-422-59-4683)
FAX:0422-59-5636 (+81-422-59-5636)
************************************

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned