Subject: [apps-discuss] APPSDIR review of draft-ietf-6man-lineid-04

From: Joseph Yee <[email-masked]>
Date: Sat, 2 Jun 2012 18:53:35 -0400

All,

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see  http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-6man-lineid-04
Title: The Line Identification Destination Option
Reviewer: Joseph Yee
Review Date: June 2, 2012

Summary: "This draft is almost ready for publication as an Experimental RFC but has a few issues that should be fixed before publication",

Major Issues: 
	none

Minor Issues: 
	section 6.2, 8th line
	"advertisement(es.  The Edge Router then forms...."
	There is no matching close bracket thru the rest of paragraph & section.  This may be a typo (nits), but I am not entirely sure, so I put it as minor.

	section 6.2, line 15
	"All BBF Access Nodes multicast address [to be allocated]..."
	Shouldn't this document define the address for IANA consideration?  If it's to be determined by WG before Last Call or to be documented (or already documented) by another RFC, please ignore.

Nits: 
	none

Note and Question
This is just my personal thought and question, it may be just my lack of knowledge in the subject matter.

If I am right, this drafts is to help making distinction at Edge Router if multiple end point or AN do not use vLAN (hence N:1).
In section 2, it says that it's experimental and not recommend for general deployment.  If it's not recommended, what's missing to make it "safe" or "good enough" for general deployment?  Is it something to do with 1:1 or vLAN environment to know how to handle ILO data first?  Would it better to document the issues in security consideration? or expand section 2 a bit more?

Regards
Joseph

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 6 Jun 2012 10:44:59 -0400

Hi Joseph,
   Thanks for your comments. Please find responses inline.

On 06/02/2012 06:53 PM, Joseph Yee wrote:
> 	There is no matching close bracket thru the rest of paragraph&  section.  This may be a typo (nits), but I am not entirely sure, so I put it as minor.

It was a typo. It has been fixed in -05.

> 	Shouldn't this document define the address for IANA consideration?  If it's to be determined by WG before Last Call or to be documented (or already documented) by another RFC, please ignore.

IANA will allocate a free address out of the multicast address block. We 
are guessing that it is going to be FF02:0:0:0:0:0:1:7, but the actual 
value is not that important.

> In section 2, it says that it's experimental and not recommend for general deployment.  If it's not recommended, what's missing to make it "safe" or "good enough" for general deployment?  Is it som…

The basic issue is that Router Solicitations are not retransmitted 
reliably until a router is found. If the home ethernet link comes up 
before the DSL line comes up, the RSs will never be retransmitted by the 
host to reach the edge router. This is why the draft is targeted only to 
scenarios where there is no other way of distinguishing multiple 
subscriber premises (n:1 vlan).

Thanks
Suresh